Business intelligence (BI) merupakan teknologi, aplikasi, atau pekerjaan mengumpulkan, mengintegrasikan, menganalisa, dan mempertunjukkan informasi bisnis dan kadang-kadang informasi itu sendiri. Kegunaan dari BI adalah untuk membantu mendapatkan keputusan bisnis yang lebih baik. Sehingga BI disebut juga sebagai DSS (Decision Support System).
BI memberikan pandangan-pandangan operasi bisnis mulai dari yang sudah lewat, masa sekarang, serta masa depan (ramalan). Kebanyakan data diambil dari data warehouse atau data mart dan kadang-kadang dari data operasional.
BI seringkali menggunakan KPI (key performance indicators) untuk menentukan kondisi bisnis dan memberikan saran-saran apa yang harus dilakukan. Sebelum adanya teknologi komputer, perhitungan-perhitungan yang melibatkan KPI sangat sulit dan bisa menghabiskan waktu berminggu-minggu sampai berbulan-bulan. Namun sekarang kita bisa melakukannya dengan jauh lebih cepat (dalam semingguan atau malah harian)...
Pemain Business Intelligence
Di bawah ini adalah gambar magic quadrant dari Gartner yang terbaru (Januari 2008) yang menggambarkan peta pemain Business Intelligence :
Microsoft merupakan satu leader dengan kemampuan eksekusi yang paling baik.
- Solusi Microsoft terutama sangat menarik untuk perusahaan yang sudah memiliki infrastruktur Microsoft, karena harga bundle yang begitu ekonomis
- Microsoft juga didukung oleh komunitas pengembang aplikasi yang besar. Dibandingkan para pesaing, Microsoft melengkapi para pengembang dengan kemampuan tool, workflow, kolaborasi yang jauh lebih baik
- Microsoft diuntungkan oleh pejualan tidak langsung dan tingkat popularitas yang tinggi dari SQL Server, Office, dan SharePoint Portal. Pelanggan yang membutuhkan BI biasanya menginginkan penawaran yang sama untuk barang dan jasa dari mitra bisnisnya
- Microsoft juga memiliki kualitas BI yang terbaik dibandingkan dengan vendor-vendor besar lainnya. Ini menandakan Microsoft memang sangat menaruh perhatian pada BI, tim pengembangnya, dan fakta bahwa teknologi BI Microsoft memang dikembangkan sendiri, bukan hasil akuisisi
BI terdiri dari Data Warehousing, Reporting & Analysis, dan Performance Management.
Data Warehosing
Data Warehousing (misalnya menggunakan Microsoft SQL Server) merupakan satu komponen yang sangat penting di dalam BI :
- Menggabungkan semua data dari semua sumber yang ada di dalam organisasi ke dalam satu platform yang terintegrasi
- Fasilitas untuk menganalisa data yang memungkinkan kita mengolah data dengan bermacam-macam cara supaya menghasilkan hasil yang bermanfaat untuk pengambil keputusan dan juga untuk keperluan pengolahan KPI (key performance indicator)
- Bermacam-macam cara analisa data dengan cara yang mudah
- Fungsi pelaporan yang bagus dan interaktif dengan format yang mudah untuk dibaca banyak orang
Reporting & Analysis
Reporting : Business Intelligence membutuhkan teknologi dan sistem pelaporan dan analisa untuk mendapatkan informasi yang terstruktur ataupun tidak. Sistem pelaporan ini bisa didapatkan dari kemampuan Microsoft SQL Server, atau Microsoft Office PerformancePoint Server.
Analysis: Di dalam solusi Microsoft, analysis tool sudah terintegrasi di dalam platform BI untuk membantu kita mengubah data menjadi informasi yang berguna. Contohnya, dari informasi yang sama, kita bisa melihat scorecard kemudian berpindah ke pembacaan laporan dengan mudah. Hal ini sangat membantu para pengambil keputusan untuk melihat dari segala sisi dan menghindari hal-hal yang tersembunyi.
Performance Management
Ada tiga komponen dari Performance Management yang paling penting :
- Monitoring - kemampuan untuk memonitor scorecards, dashboards, dan KPI yang diperlukan suatu perusahaan untuk menyelaraskan organisasi dan pengaturan tanggung jawab
- Analitik - kemampuan analisa informasi yang hasilnya bisa dipergunakan bersama-sama dalam suatu perusahaan
- Perencanaan - merupakan suatu kerangka kerja yang memberikan fungsi-fungsi manajemen untuk perencanaan bisnis, budgeting, dan forecasting untuk keperluan pengambilan keputusan yang strategis
Sumber :
http://en.wikipedia.org/wiki/Business_intelligence
http://mediaproducts.gartner.com/reprints/microsoft/vol7/article3/article3.html
11 comments:
terimakasih atas artikelnya, sangat bermanfaat.
Pak toni bedanya antara BI dan DSS itu kan pasti ada, kira-kira perbedaan secara prinsip apa ?
terima kasih
Halo Pak Toni...
Saya mau tanya sedikit mengenai Data Warehouse (DWH) dan Business Intelligence (BI):
1. Kapan kita harus memutuskan/memilih untuk memakai Star Schema atau Snow Flake Schema?
2. Bagaimana mengurangi beban pada retrieving data dengan banyaknya data pada Fact table? Pembagian Fact tabel dengan cara mempartisinya memang sedikit banyak membantu namun ketika harus melakukan pengecekan secara manual ke DWH maka sangatlah sulit dengan pencarian dari Fact yang sama namun berbeda tabel.
3. Bagaimana menghindari terjadinya data repetition pada Star Schema dengan jumlah data terhitung besar? Menurut yang saya alami, penggunaan Snow Flake Schema pada jumlah data yang besar akan membutuhkan waktu yang cukup lama bahkan bisa sangat lama sekali.
4. Misal, dalam report dikehendaki untuk menampilkan data dengan formulasi kompleks. Sebaiknya perhitungan tersebut dilakukan di DWH atau di Report tersebut?
5. Bagaimana menggabungkan 2 Fact atau lebih dengan Dimension yang berbeda namun diantara 2 Dimension atau lebih tersebut beberapa diantaranya memiliki kesamaan? Misalnya, Dimension A memiliki Fact A1, Dimension B memiliki Fact B1. Masing-masing Fact A1 & B1 serta Dimension A & B jelas berbeda, namun jika dilihat ternyata di dalamnya ada data yang sama misalnya Nama.
6. Bolehkah Fact mempunya Child?
7. Apa bedanya OnLine DWH dengan OLTP? Setau saya DWH itu selalu H-1 atau paling tidak ada jeda waktu dari OLTP ke DWH untuk melakukan transformasi data. Apa jadinya dengan OnLine DWH bila data tersebut dikirim bersamaan bersama transaksi kemdian ada report ingin membacanya?
8. Apakah Dimension Date (tanggal, waktu atau time dsb) diperlukan bila isi dalam Dimension tersebut hanya ada Date saja sedangkan disetiap Dimension lainnya dan juga Fact sudah ada Field Date?
9. Bila saya punya 1 RDBMS yang detail dan semua informasi yang diperlukan oleh DWH ada di situ semua (source data bukan berasal dari multiple sources tapi hanya dari 1 single source saja) apakah masih perlu dibuatkan lagi DWH? Yang saya tau DWH bisa berasal dari Relational DWH.
10. Apa yang harus dibuat di OLAP dengan DWH yang dihasilkan? Pengambilan seluruh nilai DWH ke OLAP tampaknya akan memakan storage besar-besaran, lagipula OLAP rasanya tidak mungkin untuk menarik seluruh data yang ada di DWH karena konsepnya adalah multiple views analysis, setiap point of view mempunyai indeks sendiri. Bayangkan bila terdapat misalnya 50-60 Dimensi besar di mana masing-masing punya Child sendiri-sendiri dan mengakses ke beberapa Fact? Sebagai tambahan yang saya ketahui, DWH diperuntukkan untuk pengambilan data dalam jumlah besar namun penarikan secara langsung akan membutuhkan waktu sedangkan OLAP diperuntukkan untuk pengambilan data dalam jumlah lebih sedikit/terbatas namun dengan waktu yang lebih cepat.
Terimakasih..
Agung
1. Kapan kita harus memutuskan/memilih untuk memakai Star Schema atau Snow Flake Schema?
Dalam penggunaan metode Dimensional Modelling, sebisa mungkin Snow Flake tidak pernah di consider, karena akan mempersulit proses populasi table, dan juga menyebabkan proses query untuk analisa dan reporting lebih complex, karena jumlah tabel yang terlibat akan semakin banyak. Dalam skenario Slowly Changing Dimension juga akan makin ribet karena tabel2 yang harus di deteksi existensi data2 untuk diupdate/insert juga akan banyak.
2. Bagaimana mengurangi beban pada retrieving data dengan banyaknya data pada Fact table? Pembagian Fact tabel dengan cara mempartisinya memang sedikit banyak membantu namun ketika harus melakukan pengecekan secara manual ke DWH maka sangatlah sulit dengan pencarian dari Fact yang sama namun berbeda tabel.
Ada banyak faktor untuk meningkatkan performan retrieving data yang besar dari satu table dan ini juga sangat tergantung dengan bagaimana data model nya didesain dan pembagian2 fact table yang berbeda. Dengan metode Partitioned table, yang umumnya dilakukan adalah dengan mempartisi satu table besar (Fact or Transaction) menjadi tersimpan ke beberapa storage (container atau filegroups) disk yang terpisah, bukan dengan cara menyimpan ke beberapa table yang berbeda (Fact_January, Fact_February, Fact_March, etc), melainkan satu table Fact (asumsi SQL Server) akan memiliki beberapa filegroups yang digunakan untuk menyimpan data berdasarkan partition key yang diinginkan (by Time Period, atau by Product, by Branch, etc).
3. Bagaimana menghindari terjadinya data repetition pada Star Schema dengan jumlah data terhitung besar? Menurut yang saya alami, penggunaan Snow Flake Schema pada jumlah data yang besar akan membutuhkan waktu yang cukup lama bahkan bisa sangat lama sekali.
Penganut Star Schema mempopulerkan istilah Conformed Dimension, jadi untuk Dimensi2 yang umumnya memiliki sifat yang sama, untuk suatu skenario Data Warehouse di perusahaan, haruslah didesain Data2 Dimension yang sama, dan ini tinggal di link/digunakan lagi di berbagai fact table yang akan digunakan lagi. Namun, kelemahan utama Star Schema (seandainya Data Modeller nya kurang cukup berpengalaman dalam pemodelan yang complex) adalah karena dia terutama diperuntukan untuk spesifik kebutuhan analisa tertentu (scope yang terbatas). Karena itu fact table yang dihasilkan fari Star Schema seringkali hanya bisa untuk memenuhi kebutuhan analisa yang sudah spesifik tidak bisa dikembangkan lagi, seandainya ada kebutuhan baru, perubahan pada data modelnya akan complex dan perubahan pada proses populasinya (ETL) juga lebih susah lagi karena data historical nya juga harus berubah, karena itu seringkali jalan pintas yang dilakukan adalah dengan membangun fact table yang baru, nah dengan cara ini data repetitif tidak bisa dihindari.
Ada pendekatan yang agak berbeda yang mungkin bisa coba dipelajari, yaitu Hybrid Modelling yang merupakan penggabungan Normalized Data Model dan Star Schema Data Model, dimana ada pendekatan SOR dan Data Marts.
4. Misal, dalam report dikehendaki untuk menampilkan data dengan formulasi kompleks. Sebaiknya perhitungan tersebut dilakukan di DWH atau di Report tersebut?
Sangat tergantung dengan kompleksitas yang dihadapi. Seandainya proses kalkulasinya kompleks namun hanya melibatkan field2 yang sudah ada di fact table, proses di Report bisa dilakukan. Namun jika kompleksitas yang dimaksud ini akan melibatkan proses kalkulasi dalam jumlah data yang besar dan harus mereferensi ka tabel2 yang lain, proses sebaiknya dilakukan di ETL sebelum ke DWH atau juga di DWH setelah data masuk semuanya namun sebelum report dihasilkan.
5. Bagaimana menggabungkan 2 Fact atau lebih dengan Dimension yang berbeda namun diantara 2 Dimension atau lebih tersebut beberapa diantaranya memiliki kesamaan? Misalnya, Dimension A memiliki Fact A1, Dimension B memiliki Fact B1. Masing-masing Fact A1 & B1 serta Dimension A & B jelas berbeda, namun jika dilihat ternyata di dalamnya ada data yang sama misalnya Nama.
Kembali lagi, seharusnya menerapkan konsep Comformed Dimension seandainya dimensi yang digunakan memiliki kesamaan. Untuk fact table sendiri, ini sangat tergantung dengan desain dan data yang ada, namun tidak ada jalan yang mudah. Seandainya mungkin data2 itu di'setarakan' sehingga bisa di-join langsung. Disetarakan dalam artian memiliki level dimensi (seandainya ada hierarchy) dan Time Period yang sama.
6. Bolehkah Fact mempunya Child?
Saya tidak melihat keperluan memiliki child? Untuk apa, akan semakin ribet aja querynya tuh.
7. Apa bedanya OnLine DWH dengan OLTP? Setau saya DWH itu selalu H-1 atau paling tidak ada jeda waktu dari OLTP ke DWH untuk melakukan transformasi data. Apa jadinya dengan OnLine DWH bila data tersebut dikirim bersamaan bersama transaksi kemdian ada report ingin membacanya?
Online DWH itu tidak Real-Time, tetap Near Real-time, namun jeda waktunya bukan H-1, tapi bisa saja H-1jam etc, tetap akan ada jeda waktu.
8. Apakah Dimension Date (tanggal, waktu atau time dsb) diperlukan bila isi dalam Dimension tersebut hanya ada Date saja sedangkan disetiap Dimension lainnya dan juga Fact sudah ada Field Date?
Dalam pemodelan Data Warehouse yang baik, Time Period Dimension sebaiknya didefinisikan secara lengkap dengan surrogate keynya juga, karena sewaktu2 proses query bisa saja membutuhkan data2 yang tidak hanya Date saja (Week, DayofMonth, DayofYear, FiscalMonth, etc). Sedangkan di fact table, seharusnya Time Dimension memiliki Surrogate Key yang disimpan di Fact table dan mereferensikan dengan data di Time Dimension.
9. Bila saya punya 1 RDBMS yang detail dan semua informasi yang diperlukan oleh DWH ada di situ semua (source data bukan berasal dari multiple sources tapi hanya dari 1 single source saja) apakah masih perlu dibuatkan lagi DWH? Yang saya tau DWH bisa berasal dari Relational DWH.
Seandainya 1 RDBMS itu bukan merupakan Application atau OLTP tapi merupakan suatu DWH atau Data Mart, ya tidak perlu. Tapi seandainya itu merupakan OLTP, tentu saja perlu, karena query2 analytical memiliki data model yang berbeda dengan OLTP itu.
10. Apa yang harus dibuat di OLAP dengan DWH yang dihasilkan? Pengambilan seluruh nilai DWH ke OLAP tampaknya akan memakan storage besar-besaran, lagipula OLAP rasanya tidak mungkin untuk menarik seluruh data yang ada di DWH karena konsepnya adalah multiple views analysis, setiap point of view mempunyai indeks sendiri. Bayangkan bila terdapat misalnya 50-60 Dimensi besar di mana masing-masing punya Child sendiri-sendiri dan mengakses ke beberapa Fact? Sebagai tambahan yang saya ketahui, DWH diperuntukkan untuk pengambilan data dalam jumlah besar namun penarikan secara langsung akan membutuhkan waktu sedangkan OLAP diperuntukkan untuk pengambilan data dalam jumlah lebih sedikit/terbatas namun dengan waktu yang lebih cepat.
OLAP dibuat berdasarkan kebutuhan analisis, tidak seluruh data warehouse akan dicemplungkan di data warehouse, harus ada kebutuhan analisa yang jelas yang akan dibuatkan cube2 OLAP nya. Data bisa ada di DWH tanpa perlu ada OLAP, tapi seluruh data OLAP harus berasal dari DWH.
Dear Pak Endy Lambey,
Terimakasih atas jawabannya namun saya masih bingung dengan jawaban Bapak yang no. 3. Mungkin lebih jelas bila saya berikan contoh dari apa yang saya maksud sebelumnya:
Tabel Dim_Prod: Tabel Fact_Prod:
------------------------ -------------------------
Level1 Level2 Level2 Value
----------------------------------------- ------------------------------------
A A1 A1 50
A A2 A2 30
A A3 A3 20
B B1 B1 100
C C1 C1 40
C C2 C2 60
D D1 D1 100
Di mana: Dim_prod dengan Surrogate Key Level2 (Level2 adalah level terendah/leaf)
Fact_Prod dengan Foreign Key Level2
Dari sini terlihat bahwa pada tabel Dim_Prod, Parent (Level1) di atas untuk "A" memiliki Child (Level2) "A1" - "A2" - "A3", Parent "B" hanya mempunyai Child "B1", Parent "C" mempunyai Child "C1" - "C2" dan Parent D mempunyai Child "D1".
Berarti pada tabel Dim_Prod yang memiliki data repetition adalah Parent "A" dan Parent "C".
Jika dilihat dari tabel di atas, Parent "A" mempunyai total Value 100, Parent "B" dengan total Value 100, Parent "C" dengan total Value 100 dan Parent "D" dengan total Value 100.
Jika sbg contoh dilakukan Query untuk mendapatkan nilai Parent "A" di atas sbb:
SELECT Dim_Prod.Leve1, Fact_Prod.Value FROM Dim_prod, Fact_Prod
WHERE Dim_prod.Level2 = Fact_Prod.Level2 AND Dim_prod.Level1 = "A"
Maka akan menghasilkan result sebagai berikut:
Level1 Value
-------------------------------------
A 50
A 30
A 20
Karena Parent "A" mempunyai Child sebanyak 3 maka akan berulang sebanyak 3 kali.
Selain itu dalam SQL kita juga dapat melakukan SUM sbb:
SELECT Dim_Prod.Leve1, SUM(Fact_Prod.Value) FROM Dim_prod, Fact_Prod
WHERE Dim_prod.Level2 = Fact_Prod.Level2 AND Dim_prod.Level1 = "A"
Maka akan menghasilkan result sebagai berikut:
Level1 Value
-------------------------------------
A 100
Permasalahannya adalah ada Tool BI (mungkin tidak semua) ketika menarik Fact untuk Level1 "A" dia melakukan Aggregate SUM namun karena posisi Fact_Prod merupakan Child dari Parent Dim_Prod maka Level1 "A" ditarik berulang sebanyak jumlah Level1 "A" itu yaitu sebanyak 3 dan nilai yang ditarik totalnya menjadi 3*100=300.
Inilah yang saya maksudkan "Bagaimana meng-avoid data repetition di tabel dengan design Star Schema seperti contoh di atas?"
Terimakasih,
Satriaji
Kelemahan utama pembuatan hirarki yang didefinisikan dengan relational database biasa adalah hal yang disebutkan oleh Agung, dan susah sekali dengan tool reporting secanggih apapun kalo langsung akses ke relational data mart (star schema or whatever) yg ada di relational database untuk bisa membangun "ragged" hierarki ini.
Jawabannya adalah dengan menggunakan OLAP database atau multidimensional database yang mendukung pendifinsian hirarki dimensi dengan berbagai skenario. Microsoft SQL Server 2008 Analysis Services mendukung proses ini, lebih jelasnya bisa lihat di http://msdn.microsoft.com/en-us/library/ms174935.aspx
Tepat sekali..itulah masalahnya. Selama mendisain dengan MOLAP saya tidak mempunyai kendala dengan data repetition namun ketika membentur ROLAP mau tidak mau saya harus mengakses langsung ke Data Warehouse walaupun sudah melalui virtual cube.
Kalau begitu apa saran dari anda bila dalam kasus real harus menggunakan tool BI yang hanya support ROLAP dan bagaimana caranya agar bisa menghindari data repetition tersebut?
Terimakasih.
Untuk tools yang hanya bisa mengakses Data Mart RDBMS (bukan ROLAP, karena ROLAP adalah storage option untuk OLAP, berbeda dengan Data Mart on RDBMS), tergantung toolsnya.
SQL Server tools pastinya mendukung hal ini karena bisa langsung dikombinasi dengan fitur RDBMS dan OLAP (Analysis Services) dan diakses dengan Reporting Services (yang merupakan satu kesatuan produk SQL Server), ataupun excel.
Nah untuk non MS product, hmmm, tricky, karena ada database2 yang mendukung OLAP queries langsung di level RDBMS. Jadi kita bisa melakukan query yang membentuk hierarchy langsung di level RDBMS nya. Dengan asumsi table hierarchy nya adalah dalam bentuk parent-child relationship, tinggal dilakukan ‘OLAP’ query langsung di table itu untuk membangun hirarkinya dan bisa dijadikan view atau MQT. Dengan dasar itu, bisa dibangun Data Mart dengan menjoin MQT itu dengan data fact table.
Contoh menarik lain yang bisa dilihat di link ini http://www.rittmanmead.com/2007/06/21/obiee-data-modeling-tips-3-ragged-hierarchies/
Cara lain adalah seandanya bisa di flat (flattened dimension) pastinya akan lebih enak, dan di query untuk bikin report nya dilakukan group by dan where condition dengan subquery2 yang cukup complex. Namun yang pasti, dengan tanpa menggunakan OLAP engine, ragged hirarki ini sangat ribet untuk dihandle.
So my suggestion? If OLAP engine is not in consideration, gak ada jalan mudah buat anda :(
Jadi apa bedanya antara Data Mart RDBMS dengan ROLAP? Yang saya ketahui Data Mart RDBMS adalah desain Data Warehouse (star schema ataupun snowflake schema) sebagai tempat penyimpanan data sedangkan ROLAP adalah suatu cara/metode dari Tool BI untuk merepresentasikan struktur yang ada di DWH/Data Mart RDBMS. Misal, untuk tool BI yang tidak memiliki kemampuan akses langsung ke Multidimensional OLAP (MOLAP) maka satu-satunya cara adalah dengan membuat semacam Virtual Cube dimana mereka membuat sendiri Hirarki-hirarki semacam MOLAP dalam Tool BI mereka di mana nantinya hirarki-hirarki tersebut akan dipetakan ke DWH/Data Mart RDBMS untuk Data Retrieval. Dari hasil representasi DWH/Data Mart RDBMS ke MOLAP tersebut maka seolah-olah pengguna Tool BI tersebut seperti mengakses data dari MOLAP langsung hanya bedanya dengan ROLAP data yang disimpan masih di DWH/Data Mart RDBMS sedangkan MOLAP mempunyai tempat penampungan data tersendiri. Mohon koreksinya...
Sampai dengan saat ini, untuk menghindari Data Repetition di ROLAP dengan akses data langsung ke DWH, cara yang saya gunakan adalah dengan menggunakan Normalized Table dengan bentuk 3-NF. Dan memang sampai dengan saat ini masalah tersebut dapat teratasi namun masalah lainnya muncul yaitu dengan sangat lambatnya performance apalagi ketika harus melakukan penarikan data dengan jumlah Dimension dan Fact yang sangat banyak belum lagi ditambah dengan kondisi-kondisi tertentu. Untuk data kecil mungkin tidak begitu masalah namun ketika harus menghadapi data besar yang sudah lebih dari 1 tahun di mana per harinya mencapai 8GB atau bahkan lebih bisa dibayangkan apalagi bila ada user yang menginginkan akses Drill-Down sampai dengan level Transaksi dan yang mengakses bisa lebih dari 1 user (sampai saat ini kira-kira 12-16 user pada saat bersamaan).
Kalau dilihat dari reviewnya memang MS SQL Server 2005/2008 (SQL 2005/2008) menawarkan solusi ROLAP, MOLAP & HOLAP. Namun ada issue juga yang mengatakan bahwa SQL 2005/2008 sangat berat untuk mengakses data Drill-Down sampai ke level Transaksi, apa benar? Saya tertarik untuk mempelajari lebih dalam mengenai SQL 2005/2008 ini secara lengkap mulai dari SSIS, SSAS & SSRS (apa bedanya dengan Silverlight?). Saya juga tertarik untuk mempelajari produk Non-BI Microsoft lainnya untuk Planning & Budgetting Consolidation (apa namanya?). Apa sekiranya anda dapat memberikan referensi di mana saya bisa memperoleh buku, literatur maupun tempat kursusnya? Terimakasih.
Point tentang ROLAP, anda benar kok, tadinya saya berpikir anda mengartikannya purely akses ke Data Mart RDBMS, tanpa ada ‘virtual cube’ atau semantic layer.
Point tentang hirarki di RDBMS, seperti posting sebelumnya, memang lebih painful.
Point tentang issue drilling-down di OLAP SQL Server sampai ke level transaksi, hmmmm, bisa dielaborate lebih jauh, karena memang semua tool OLAP punya pendekatan yang berbeda2, dan di SQL 2008 sudah banyak improvement untuk masalah2 sebelumnya.
SSRS beda dengan Silverlight, SSRS itu reporting tool yang include dalam SQL Server.
Untuk training, bisa langsung contact ke Microsoft Learning Center seperti di Iverson (www.iverson.co.id) atau akses ke www.microsoft.com/sqlserver untuk overviewnya.
Contoh Ragged-Hierarchies yang Anda berikan memang bagus namun pusing sekali membacanya tanpa bimbingan langsung.
Kalau begitu saya ada contoh sederhana sbb:
Lev1 Val Lev2 Val Lev3 Val
---------------------------
A 1000 A1 600 A11 500
A12 100
A2 400
Keterangannya adalah sbb:
Level1 "A" mempunyai Value sebesar 1000 di mana bila di Drill-down akan terlihat Childrennya yaitu "A1" dengan Value 600 dan "A2" dengan Value 400 dan total nilainya adalah 1000. Sampai sini tidak ada masalah karena semua kolom telah terisi. Bagaimana bila Level2 "A2" tidak mempunyai Children? Apa yang terjadi bila dari Level1 mau di Drill-down sampai ke Level3? Seharusnya total Value Level1 harus sama dengan Total Value Level3 yaitu 1000. Namun yang terjadi di atas adalah Total Value Level3 adalah 600.
Apakah harus dilakukan pendefinisian tabel sbb?:
Lev1 Val Lev2 Val Lev3 Val
---------------------------
A 1000 A1 600 A11 500
A12 100
A2 400 A21 400
---------------------------+
1000 1000 1000
Dengan kata lain kita harus mengisi kolom kosong dengan nilai sebelumnya untuk menyeimbangkan nilai.
Mohon koreksinya dan adakah cara lainnya yang lebih tepat? Terimakasih.
Post a Comment