Apakah pemahaman saya tentang granularity tabel fakta benar?

Saya dan DBA lain di perusahaan kami ditugasi meninjau desain basis data yang telah dikembangkan vendor untuk kami. Vendor mengatakan mereka menggunakan Kimball sebagai dasar untuk desain mereka. (CATATAN: Saya tidak mencari argumen Kimball vs Inmon, dll.) Mereka telah merancang mart dengan banyak fakta dan dimensi.

Sekarang dalam semua keadilan, perusahaan kami tidak pernah mendesain satu pun mart. Kami selalu meminta para konsultan untuk melakukannya. Dan kami belum pernah dikirim ke kelas atau apa pun. Jadi pengetahuan kita tentang pergudangan / mart / pemodelan dimensi, dll. Didasarkan pada sedikit pengalaman yang kita miliki, apa yang dapat kita temukan di Internet, dan membaca sendiri (kita memiliki buku-buku Inmon dan Kimball dan sedang mencoba untuk menerobosnya) .

Sekarang setelah tahap set untuk tingkat pengetahuan saya, kami sampai pada tantangan desain.

Ada tabel Fakta yang disebut "Statistik Kehilangan Klaim" (ini untuk asuransi). Dan mereka mencoba untuk menangkap pembayaran untuk klaim (digulung ke tingkat bulanan), dan kemudian uang dalam cadangan (seperti rekening bank untuk klaim). Mereka ingin melihat jumlah bulanan untuk pembayaran (bukan masalah besar). Tetapi mereka ingin melihat saldo saat ini dari cadangan.

Saya akan memberikan contoh gambar.

Katakanlah kita menyiapkan cadangan $ 1000 USD untuk klaim. Ini dikesampingkan (jadi dalam beberapa hal berfungsi seperti rekening bank).

Pada bulan Oktober 2014, kami belum membayar apa pun. Jadi bisnis ingin melihat pembayaran dan saldo cadangan pada akhir Oktober.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------

Lalu November datang. Kami melakukan pembayaran $ 100, $ 150, dan $ 75 dolar. Mereka ingin melihat jumlah yang dikumpulkan dan cadangan pada saldo sebagai berikut:

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------

Dan kemudian katakan kita tidak memiliki pembayaran pada bulan Desember dan kemudian $ 200 lebih pada bulan Januari tahun depan.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------
-      122014  -      0.00 -           675.00 -
-----------------------------------------------
-       12015  -    200.00 -           475.00 -
-----------------------------------------------

Di sinilah saya berjuang. Pemahaman saya adalah bahwa bagian pembayaran sudah benar. Mereka semua digulung pada level bulanan dalam setiap catatan. Jadi Anda dapat melanjutkan lebih jauh jika Anda ingin untuk tahun ini, kuartal, dll.

Tetapi jumlah cadangan berbeda. Itu adalah keseimbangan. Dan bisnis ingin melihat berapa banyak saldo di setiap bulan. Tetapi Anda tidak dapat mengumpulkan di bidang ini. Jika Anda melakukannya, Anda akan mendapatkan beberapa hasil yang buruk.

Entah bagaimana ini menurut saya salah. Tetapi saya tidak dapat dengan jujur ​​mengatakan bahwa saya telah cukup mencontoh atau cukup tahu. Yang bisa saya katakan adalah apa yang saya tahu. Dan dari apa yang saya tahu, semua nilai dalam Fakta harus pada rincian yang sama.

Kedua angka itu pada granularity yang sama dari "bulan", tetapi mereka tidak dari sudut pandang apa yang mereka perjuangkan. Salah satunya adalah agregat dolar dalam sebulan. Yang lainnya hanyalah keseimbangan.

Apakah ini benar? Saya telah mendorong kembali desain ini. Apakah saya salah melakukannya? Apakah boleh melakukan ini dalam Fakta? Atau apakah "bau kode" saya tentang desain yang buruk akurat?

Bantuan apa pun akan dihargai. CATATAN: tolong jangan hanya mengatakan "Itu harus seperti X", tolong jelaskan mengapa itu harus seperti itu sehingga saya bisa belajar dari ini.

EDIT : Ya, saya belajar bahwa pemahaman awal saya tentang Fakta itu salah. Granularitas BUKAN bulanan. Granularity adalah level transaksi. Jadi itu berarti dalam MONTH_YEAR (yaitu benar-benar periode pelaporan keuangan) akan ada beberapa transaksi pembayaran dan pemulihan. Itu akan diposting berdasarkan tanggal atau tanggal transaksi. Tetapi karena laporan sebelumnya yang dilihat oleh bisnis, dan juga karena bagaimana data disimpan dalam sistem legacy dari mana mereka ingin memasukkan data transaksional (satu baris per) dan cadangan saldo bulanan (satu baris per bulan) ).

Setelah saya mengetahui hal itu, saya menyadari bahwa masalahnya bukan pada aditif vs non-aditif, atau bahkan semi aditif seperti butiran, yang saya curigai sejak awal. Tim DBA kami mendiskusikan hal ini dengan tim proyek dan melaporkan bahwa mereka berusaha untuk menempatkan dua butir yang berbeda dalam fakta yang sama, dan ini tidak benar. Bahwa mereka harus turut meningkatkan transaksi ke tingkat bulanan, memungkinkan mereka untuk kemudian memiliki pembayaran, pemulihan, dan saldo cadangan bulanan (yaitu fakta semi-aditif) karena semuanya akan menjadi gandum bulanan. Atau mereka perlu menemukan cara untuk memecah saldo cadangan menjadi transaksi untuk mempertahankan tingkat transaksi gandum. Atau mereka perlu memecah fakta menjadi dua fakta. Satu bisa menjadi level bulanan untuk saldo cadangan. Yang lain dapat berada di tingkat transaksi untuk pembayaran dan pemulihan. (Tidak ada alasan mengapa mereka juga tidak bisa menempatkan pembayaran dan pemulihan pada tingkat bulanan juga pada tingkat bulanan. Hanya tergantung pada kebutuhan bisnis.)

Mengingat apa yang telah saya pelajari, saya akan menandai jawaban Thomas sebagai jawaban yang benar. Namun, saya merasa diskusi yang saya mulai dengan pertanyaan asli masih bagus untuk dipelajari orang lain, jadi saya akan membiarkan bagian asli dari pertanyaan saya tetap utuh. Saya juga berniat memberikan hadiah untuk jawaban nikadam karena itu mengajari saya banyak fakta tentang aditif, non-aditif, dan semi-aditif, dan mengoreksi banyak kesalahpahaman yang saya miliki tentang pemodelan dimensi.

Intuisi bau kode Anda terasah dengan baik.

Apa yang Anda hadapi reserves adalah apa yang disebut Kimball sebagai "fakta semi-aditif". Itu tidak menggulung dengan baik ke kuartal atau tahun.

Solusi khas untuk ini adalah memiliki dua tabel fakta, satu untuk fakta aditif ( paymentsdalam kasus Anda) dan satu untuk fakta non-aditif. Fakta non-aditif sebenarnya tidak perlu memiliki biji-bijian di tingkat bulan, Anda bisa menyimpannya sampai hari ini dan semuanya masih berfungsi.

Fakta non-aditif reserve,, dipertanyakan berbeda dari fakta lainnya. Ada keputusan bisnis yang perlu Anda buat: Apa artinya reservedi tingkat tahun? Apakah ini bulan terakhir tahun ini, atau mungkin rata-rata bulan dalam setahun? Apa pun pilihan yang Anda buat, Anda dapat menemukan solusi untuk memodelkannya dalam buku-buku Kimball di bawah bab-bab tentang fakta-fakta non-aditif.

Harap dicatat bahwa jika Anda menggunakan produk kubus seperti Layanan Analisis, dimungkinkan untuk memiliki agregat "hanya berfungsi" bahkan jika Anda menyimpan semuanya dalam satu tabel. Namun, saya lebih suka untuk memisahkan hal-hal sehingga pertanyaan relasional lebih mudah untuk ditulis (dan fakta-fakta lebih mudah untuk memuat juga).

Anda benar: " butir yang berbeda tidak boleh dicampur dalam tabel fakta yang sama ".

Tetapi saldo cadangan pada akhir bulan dan jumlah pembayaran pada akhir bulan sama. Itu hanya salah satu fakta yang bersifat semi aditif . Jenis fakta (tambahan atau tidak) tidak mendefinisikan butir tabel.

Dari apa yang Anda gambarkan, saya melihat butir Anda sebagai "snapshot klaim bulanan", yang menjadikan tabel fakta Anda " tabel Fakta Snapshot Berkala ".

Dalam artikel ini Kimball memiliki contoh fakta aditif dan semi-aditif dalam tabel fakta yang sama.

Berikut adalah contoh potret berkala dengan fakta semi-aditif dari The Data Warehouse Toolkit (halaman 116):

Praktik terbaik adalah memiliki tabel fakta transaksional yang akan mencerminkan setiap perubahan cadangan (pembayaran dan penyesuaian) pada tingkat atom terendah. Ketika Anda berurusan dengan klaim, seringkali level atom bukanlah klaim tetapi sub-klaim (perusahaan asuransi Anda mungkin memiliki ketentuannya sendiri). Umumnya setiap sub-klaim akan mewakili pihak yang berbeda dengan klaim dan pembayaran / cadangan untuk masing-masing pihak. Misalnya, mungkin tidak ada pembayaran kepada tertanggung, tetapi pembayaran kepada yang tidak diasuransikan oleh orang yang dirugikan oleh perusahaan Anda dan pembayaran ke rumah sakit dan pengacara.

Bergantung pada kinerja alat BI Anda, Anda dapat menggunakan tabel fakta transaksional secara langsung untuk mendapatkan pembayaran dan saldo bulanan. Atau Anda dapat memperbarui tabel fakta snapshot berkala dari transaksional setiap hari atau pada akhir bulan.

Kemampuan menangani fakta semi-aditif akan tergantung pada lapisan BI apa yang Anda gunakan. Beberapa alat dapat dengan mudah menangani fakta semi-aditif dan beberapa tidak.

Buku utama Kimball ( The Data Warehouse Toolkit ) memiliki bab lengkap (16) tentang asuransi.