Fakta perbandingan yang berubah-ubah Misalkan Pebisinis ingin menunjukan kemampuannya dalam melaporkan harga pada fakta standar

Numerik, seperti keseimbangan perhitungan, tetapi tidak sama dengan harga yang telah di tentukan, Mereka mungkin ingin membuat laporan yang terlihat mirip ,berikut bisa jadi landasanya, berdasarkan gambar dari saldo rekening berikut:

Dengan Menggunakan skema pada Gambar 9.2, sulit untuk membuat laporan ini langsung dari tabel . SQL tidak memiliki generalisasi dari klausa GROUP BY yang rumpun aditif ke dalam rentang nilai. Untuk lebih memperumit masalah, rentang adalah setara ukuran, dan memiliki nama tekstual seperti "10.001 dan up". Juga, pengguna biasanya perlu fleksibilitas untuk mendefinisikan kembali harga pada saat query dengan batas-batas yang berbeda atau tingkat presisinya.

Skema yang ditunjukkan dalam Gambar 9.4 memungkinkan kita untuk melakukan penilaian terhadap harga serta dalam hal pelaporan. Tabel definisi harga dapat mengandung banyak set yang berbeda, dan harga sesuai seperti yang diinginkan.

Mengontrol

kinerja

query

ini

bisa

menjadi

suatu

tantangan.

Dengan

definisi,

nilai harga query yang sangat ringan dibatasi. Contoh laporan kami diperlukan untuk memindahkan saldo lebih dari 90.000 rekening. Mungkin hanya dibatasi dengan dimensi tanggal dan berapa bulan telah berjalan. Selanjutnya, tidak konvensional jika di definisikan ; semua dilakukan untuk mengelompokkan saldo 90.000. Dalam situasi ini Anda perlu menempatkan indeks langsung pada fakta keseimbangan. Kinerja query yang membatasi atau kelompok pada nilai dari suatu fakta, seperti keseimbangan, akan meningkat dengan sangat besar, jika database manajemen sistem (DBMS) dapat mengurutkan dan mengkompres oleh produk fakta individu IQ pada secara efisien. Pendekatan awal 1990-an dan semacam itu dirintis standar Sybase sekarang menjadi

pengindeksan pada beberapa DBMS. Point-in-Time Balances/ saldo point-in-times Sejauh ini kita telah membatasi diskusi kita dalam bab ini, yaitu jasa keuangan untuk akhir bulan, dan keseimbangan terhadap snapshot, karena untuk detail biasanya sudah cukup untuk analisis. Jika diperlukan, kita bisa melengkapi snapshot bulanan-grained Bahkan dengan tabel fakta kedua yang menyediakan snapshot terbaru. Membuat keseimbangan snapshot untuk sebuah bank besar perlu rentang waktu akan sangat panjang bank dalam melakukannya 10 juta rekening, mengingat kepadatan data yang ada. Jika memiliki snapshot harian menerjemahkan menjadi sekitar

Bahkan baris 3,65 miliar per tahun.

Dengan asumsi bahwa persyaratan bisnis yang sudah telah mendorong kebutuhan untuk membuat data detail transaksi tersedia untuk analisis, kita dapat memanfaatkan transaksi ini rinci untuk menentukan keseimbangan titik-in-time sewenang-wenang. Untuk menyederhanakan masalah, kita akan mengecilkan tabel account transaksi Bahkan turun ke desain yang sangat sederhana , seperti yang diilustrasikan pada Gambar 9.5. Kunci jenis transaksi bergabung untuk tabel yang dimensinya kecil dan jenis transaksi yang diperbolehkan. Urutan transaksi adalah nomor account pada dalam numerik terus jangka meningkat waktu dan seumur berjalan hidup. untuk

Seperti fakta dari semua transaksi-grained tabel, kita menambahkan baris untuk tabel fakta di Gambar 9.5 hanya jika transaksi terjadi. Jika account diam selama dua minggu, mungkin rekening mencari transaksi paling baru baris Bahkan sebelumnya untuk setiap account pada atau sebelum tanggal yang diminta. Berikut contoh kode SQL nya: 1 Januari hingga 14, waktu tidak itu. akan ada baris dalam kita tabel ingin fakta tahu untuk apa selama rentang Namun, misalkan

yang terjadi pada semua saldo akun tersebut pada tanggal 5 Januari? Dalam hal ini kita perlu

Dalam contoh ini kita mengambil keuntungan dari situasi khusus yang ada dengan kunci pengganti tanggal. Sebagaimana kita bahas pada Bab 2, kunci tanggal adalah satu set bilangan bulat berjalan dari 1 sampai N dengan urutan, bermakna diprediksi. kami menetapkan bilangan bulat berturut-turut untuk tanggal pengganti kunci sehingga kita secara fisik. Partisi tabel fakta besar berdasarkan tanggal. Ini rapi segmen fakta

meja sehingga kita dapat melakukan tindakan administratif diskrit pada tanggal tertentu rentang, seperti pindah ke penyimpanan data arsip offline atau menjatuhkan dan membangun kunci kembali memiliki indeks. Dimensi tanggal dimensi satunya Karena yang pengganti diprediksi tertanam semi-intelijen.

urutan, itu hanya pada dimensi yang kita berani menempatkan kendala aplikasi. Memanfaatkan tabel transaksi fakta untuk tujuan ganda mensyaratkan bahwa fakta tabel adalah benar-benar lengkap dan akurat. Setiap transaksi terhadap rekening harus muncul dalam tabel fakta, atau keseimbangan tidak akan berjalandan tidak akan akurat. Sebuah baris transaksi yang datang terlambat akan memerlukan menyapu ke depan dari titik penyisipan nomor key urut tabel di account itu dan ini, incrementing meskipun adalah adalah gudang semua saldo dalam dan valid dan juga transaksi nomor urut. Perhatikan bahwa kita tidak secara eksplisit menggunakan transaksi dasar cap mudah dalam fakta, antara dari saldo diskusi yang diperlukan rekening, yang desain untuk merekonstruksi urutan sebenarnya dari transaksi andal dan untuk memberikan primary karena dapat diantaranya urut ke tanggal, ukuran dengan urutan nomor. Kami lebih suka menggunakan nomor urut daripada ofday waktuperbedaan tangan nomor metrik dari account. Teknik ini layak di beberapa bagian karena sistem pemrosesan transaksi masing-masing catatan transaksi. Berbeda dengan tahun-to-date fakta kita bahas pada Bab 8, di kasus ini saldo rekening kita tidak memiliki cara untuk menentukan saldo hanya dengan dampak saldo arena, meringkas dari account bahkan semua yang jika transaksi transaksi valid. saldo terakhir dari Untuk disediakan saja. awal Sebaliknya, keberadaan setiap bisnis kami rekening dalam transaksi, perlu untuk jasa mempelajari menghitung keuangan masih

beberapa berikut

mereka

mungkin tidak berlaku untuk titik-in-time pelaporan keseimbangan. Sebagai contoh, dalam kasus dari sebuah perusahaan pialang, jika keseimbangan penilaian diperbarui mengikuti setiap investasi, transaksi, kita tidak bisa mengandalkan bahwa keseimbangan untuk point-in-time, karena penilaian perubahan terus-menerus. Dalam kasus ini kita mungkin akan menciptakan snapshot tabel untuk menyediakan pengguna dengan teratur di akhir-periode investasi penilaian saldo.

Saldo Transaksi Tabel Fakta

Transaksi Tanggal Key (FK) Key Account (FK) Lebih Asing Tombol ... Transaksi Jenis Kunci (FK) Urutan Nomor Transaksi (DD) akhir Bendera Jumlah transaksi Transaksi Saldo Akhir
Gambar 9.5 Menggunakan tabel fakta transaksi untuk point-in-time saldo.