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.
