Dengan BI maka semua level Desicion Maker mulai dari para top level management, midle management, sampai Operational Staf dapat mengambil keputusan yang cepat dan tepat, semua stackholder akan mendapatkan Informasi menyeluruh sesuai dengan business Role nya. Perusahaan akan mempunyai ‘Single View of the Truth’ atas semua informasi pada semua level organisasi.
BI akan memberikan cara pandang yang baru terhadap berbagai level performance dari level enterprise sampai level individual staf, dari atomic transaction sampai summary transaction.

Beberapa area bisnis di Perbankan yang dapat menggunakan BI Tool:

Asset and Liability Management
- Interest Rate Sensitivity Analysis
- Liquidity Analysis
- Short term Funding Management
- Financial Management Accounting
- Capital Allocation Analysis
- Capital Procurement
- Credit Loss Provision
- Funds Maturity Analysis
- Income Analysis
- Net Interest Margin Variance
- Structured Finance Analysis
- Equity Position Exposure
- Position Valuation Analysis

Relationship Marketing
- Customer Interaction Analysis
- Customer Investment Profile
- Individual Customer Profile
- Wallet Share Analysis
- Customer Complaints Analysis
- Customer Delinguency Analysis
- Customer Loyality
- Market Analysis
- Campaign Analysis
- Cross Sell Analysis
- Customer Attrition Analysis
- Customer behavior
- Lead Analysis

Profitabilily
- Transaction Analysis
- Activity based Costing Analysis
- Insurance Product Analysis
- Investment Arrangement Analysis
- Profitabilty Analysis
- Channel Profitability
- Customer Life Time Value
- Customer Profitability
- Location Profitability
- Product Profitability
- Product Analysis
- Organization Unit Profitability
- Performance Measurement
- Business Procedure Performance

Risk
- Interest Rate Risk Analysis
- Credit Risk Profile
- Credit Risk Assessment
- Credit Risk Mitigation Assessment
- Securitization Analysis
- Operational Risk Assessment
- Outstandings Analysis
- Portfolio Credit Exposure
- Security Analysis
- Liquidity Risk
- Collections Analysis
- Insurance Risk Profile
- Authority Profiling
- Credit Risk Analysis
- Debt Restructuring
- Involved Party Exposure
- Location Exposure
- Non Performing Loan
- Operational Risk Loss Analysis

Dari semua Area yang disebut diatas, untuk Top Level Management dapat diambil beberapa Indikator yang dapat mewakili kondisi Perbankan secara keseluruhan, inilah yang disebut Banking Key Indikator.
Banking Key Indikator tersebut antar lain:

- Total Assets
- Deposits
- Loans
- Earning Asset
- Net Interest Income
- Loan to Deposit Ratio (LDR) (%)
- Return on Assets (%)
- Gross Non Performing Loans (%)
- Non Performing Loan (NPL)
- Net Non Performing Loans (%)
- Capital Adequacy Ratio (CAR) (%)
- Loans/Earning Assets (%)
- Net Interest Margin (NIM) (%)
- Liquit Assets/Total Assets (%)
- Core Deposits/Total Assets (%)
- Cost Efficiency Ratio (%)

Dari beberapa Indikator yang sudah disebutkan diatas, agar dapat dilakukan Multidimensional Analysis maka perlu dibuat
Dimensioanal Data Model dengan melengkapi apa Measurement nya dan apa saja Dimension yang terkait dengan Measurement tersebut.
Pekerjaan ini bisanya dikerjakan Data Modeler yang dibantu Banking Business Analyst atau SME untuk masing-masing Subject Area.

Setelah Data di polpulate ke Cube yang sudah dibentuk maka Informasi sudah dapat disajikan dalam bentuk Digital Dasboard,
Balance Scorecard, atau Report sesuai dengan kebutuhan User.

Beberapa keuntungan dalam menggunakan BI adalah sebagai berikut:
- Menyeimbangkan Resiko bisnis dan Perkembangan bisnis selagi mengelola Regulatory Compliance
- Memberdayakan investasi pada sumber daya yang ada dan infrastruktur nya dengan cara mengumpulkan data
dari berbagai sumber Data yang ada.
- Memenuhi kebutuhan Regulator dengan cara yang cepat dan informasi yang akurat.
- Report BI untuk memonitor performan Management di Cabang
- Menyediakan informasi yang cerdas tentang Customer untuk aktivitas promosi
- Menyediakan 360 derajad pandangan mengenai profile Customer.
- Mempermudah penilaian semua aspek performan organisasi seperti income, profit, customer satisfaction,
flexibility, perpindahan dan pertumbuhannya.
- Membantu melakukan Profit Analysis per Cabang, mencari Customer yang paling banyak memberikan keuntungan,
Service yang paling banyak memberikan keuntungan, atau Lokasi yang paling banyak memberikan keuntungan.
- Mengelola Resiko Kredit, membuat balance sheet dengan report profit/loss, menstandardisasi portfolio dan
analisa Kredit.
- Memberikan 360 derajad pandangan mengenai Finansial dan hasil-hasil Operasional.

Reff:
IBM, Banking Data Warehouse General Information Manual,
Elegantj BI, Business Intelligence and KPI for Banking

http://www.elegantjbi.com/Solutions/industry_BI_banking.htm

Secara klasik memang telah populer ada dua pendekatan dalam membangun Data Warehouse yaitu Top-Down Approach dan Bottom-Up Approach

1. Top-Down Approach
- Arsitektur ini biasa juga disebut dengan Hub-and-Spoke
Architecture (The Corporate Information Factory)
- Awalnya dibangun sebuah Enterprise Data Warehouse.
- Data level atomic disimpan dalam 3th Normal Form dalam
Enterprise Data Warehouse.
- Data akan di extract dari Source System dan di Load ke
dalam Data Warehouse pada level Granularity terendah
(Data level atomic).
- Data akan di Load kedalam Data Warehouse lewat Persistent
Staging Area.
- Data dalam Data Warehouse kemudian akan dibuat
Summary-nya, dibuat Dimensional dengan cara diteruskan ke
beberapa Dependent Data Mart, Data Mart ini hanya
menyimpan Data Summary yang disimpan dalam Star-Schema
atau Snowflake-Schema.
- User bisa melakukan Query baik ke Data Warehouse maupun
ke Data Mart
- Bill Inmon menganjurkan dan mempromosikan arsitektur ini

2. Bottom-Up Approach
- Arsitektur ini biasa juga disebut dengan The Data warehouse
Bus Structure
- Awalnya dibangun sebuah Dimensional Data Mart, belakangan
bisa dikembangkan menjadi beberapa Data Mart sesuai dengan
kebutuhan dan budget dari bisnis User.
- Data Mart mengandung baik Data atomic maupun Data
Summary
- Tidak ada model Normalized, semua Data Mart adalah
Dimensional yang diorganisasikan dalam Star-Schema
- Data yang diload ke Data Mart lewat non-persistent Staging
Area
- Penggunaan Conform Dimension adalah Mandatory, dengan
menggunakan Bus Architecture maka semua Data Mart bisa
saling terintegrasi secara logika sehingga dapat memberikan
pandangan Enterprise akan Data.
- Ralph Kimball menganjurkan dan mempromosikan arsitektur
ini

Dalam perkembangannya saat ini ada dua pendekatan lain dalam membangun Data Warehouse seperti dijelaskan dibawah ini:

3. Hybrid approach
- Methodology ini dikembangkan untuk menghindari kekacauan
Data Mart pada methodology yang ada sebelumnya.
- Dimulai dengan membuat Enterprise Data Model. Ketika
ditambahkan Data Mart, Data Model pada Data Warehouse
diperluas dengan teknik incremental Enterprise Data Model.
- Setelah Data Mart pertama selesai dibangun, dapat dilanjutkan
dengan membangun beberapa Data Mart berikutnya sesuai
dengan kebutuhan Business User.
- Data Mart dibangun lebih dahulu dibanding dengan Data
Warehouse.
Tidak seperti methodology tradisional, Data Mart di populate
dengan ETL Tool bukan dari Data Warehouse.
- Demikian juga halnya dengan Aggregate yang dihitung dengan
ETL Tool, bukan dari Data Warehouse, menggunakan teknik
Incremental Aggregation.
- Data Mart mengandung Data atomic yang relevan dengan
spesifik Business area dan juga mengandung Data Summary
atau Aggregate nya.
- Pembangunan Data Warehouse adalah opsional dan bisa
dibangun belakangan sampai diperlukan usaha untuk menekan
redudancy Data atomic atau untuk mengkonsolidasikan Data
atomic dalam satu database terpusat.
- Pembangunan ODS adalah opsional dan dapat dibuat
belakangan.
- Semua komponen dalam arsitektur ini terintegrasi dengan
metadata yang dihasilkan dan disinkronkan secara otomatis
oleh ETL Tool.
- Data yang di load kedalam dimensional Data Mart lewat
non-persistent Staging Area.
- Data Mart bersifat Dependent, namun ketergatungannya
hanya berdasarkan turunan Lokal Meta Data dari pusat Meta
Data bukan tergantung pada Data dari Data Warehouse.
- Aplikasi Data Warehouse berdasarkan arsitektur “hub-and-spoke”, namun dengan hub dari ETL Tool bukan hub dari Data Warehouse.
- Pieter Mimno, Myers & Holum yang menganjurkan dan mempromosikan arsitektur ini.

4. Federated approach
- Methodology ini sebenarnya bukan arsiktektur namun lebih
sebagai suatu Theory yang membolehkan untuk
mengintegrasikan asset Data agar dapat memuhi kebutuhan
dan untuk merespon kondisi yang dinamis.
- Menyatukan data dari berbagai sumber, termasuk dari Data
Mart atau Data Warehouse yang lain
- Memang bukan methodology yang elegan namun adakalanya
sangat berguna dan sesuai dengan banyak kebutuhan.
- Methodologi ini biasanya dianjurkan pada perusahaan yang
sudah mempunyai lingkungan Decision Support yang komplek
namun tidak ada keinginan untuk membangun ulang.
- Doug Hackney & Eckerson.yang menganjurkan dan
mempromosikan arsitektur ini.

Pada akhirnya setiap arsitektur masing-masing mempunyai Pros dan Cons sendiri-sendiri. Untuk memilih arsitektur yang paling tepat juga perlu dipertimbangkan dari sisi Business Requirement, Existing Infrastructure, Time frame dan Budget yang tersedia. Tentu diperlukan seorang Consultant yag berpengalaman agar dalam pembagunan Data Warehouse bisa Cost Efektif dan tepat guna.

Reff:
Eckerson, Wayne, Four Ways to Build a Data Warehouse, tdwi-publication, 2009.
(http://www.tdwi.org/Publications/display.aspx?id=6699&t=y)
Mimno, Myers & Holum, How to Avoid Data Mart Chaos using Hybrid Methodology, 2002
(http://www.mimno.com/articles/article5.html)
The Data Warehouse Architect, Data Warehouse Implementation Approach, 2009
(http://www.dwharchitect.com/2009/11/data-warehouse-exam-3-data-warehouse.html)

Great Debate
Arsitektur mengenai Data Mart dan Data Warehouse ini sudah lama menjadi debat yang panjang karena keduanya memang bersandar pada filosofi tentang Data Warehouse yang berbeda. Yaitu filosofi yang berbeda antara Inmon dan Kimball.

Mengenai apakah Data Warehouse dan apakah Data Mart, Kimbal dan Inmon memberikan pernyataan sebagai berikut:

“… The data warehouse is nothing more than the union of all the data marts …”
Data Warehouse itu tidak lebih dari sekumpulan Data Mart ..
Ralph Kimball Dec. 29, 1997.

Statemen ini dibalas Inmon dengan sindiran halus sbb.:
“You can catch all the minnows in the ocean and stack them together and they still do not make a whale.”
Anda dapat menangkap minnows (sejenis ikan kecil-kecil) di laut dan menumpuknya bersama dan mereka tetap tidak bisa menjadi ikan Paus.
Bill Inmon Jan. 8, 1998.

A Data Mart is a specific, subject oriented, repository of data designed to answer specific questions for a specific set of users.
So an organization could have multiple data marts serving the needs of marketing, sales, operations, collections, etc.
A data mart usually is organized as one dimensional model as a star-schema (OLAP cube) made of a fact table and multiple dimension tables.

Data Mart adalah fasiltas penyimpan data yang berorentasi pada Subject tertentu atau berorentasi pada Departemen tertentu dari suatu organisasi, fokus pada kebutuhan Departemen tertentu seperti Sales, Marketing, Operation atau Collection. Sehingga suatu Organisasi bisa mempunyai lebih dari satu Data Mart.

Data Mart pada umumnya di organisasikan sebagai suatu Dimensional Model, sperti Star-Schema (OLAP Cube) yang tersusun dari sebuah tabel Fact dan beberapa tabel Dimension.

Data Mart vs. Data Warehouse
Sebenarnya Data Mart memang tidak sama dengan Data Warehouse ada banyak perbedaanya, seperti ditunjukkan pada tabel dibawah ini:

DMvsDW

Sehubungan dengan filosofi Inmon dan Kimball yang berbeda, maka arsitektur Data Mart bisa dibedakan menjadi dua, yaitu :
Dependent Data Mart dan Independent Data Mart. Perbedaan dari kedua arsitektur tersebut hanya terletak pada ketergantungan sumber datanya terhadap data warehouse.

Dependent Data Mart

Dependent Data Mart (Inmon advocated) berlaku sebagai komponen atau suatu bagian dari enterprise Data Warehouse, Data Mart dibangun dengan cara extract data dari Data Warehouse.

Dilain pihak pada Independent Data Mart (Kimball advocated) dibangun dengan cara extract langsung data dari berbagai Source System.
Independent Data Mart tidak tergantung pada pusat penyimpan data seperti Data Warehouse arsitektur ini biasa juga disebut sebagai “Data Warehouse Bus structure”.

Independent Data Mart

Kedua arsitektur diatas menentukan bagaimana Data Mart dibangun, karena itu bisa dibedakan menjadi dua pendekatan, yakni.
1. Top-Down approach
Awalnya dibangun Enterprise Data Warehouse lebih dahulu, belakangan baru diturunkan per LOB atau departemen untuk menjadi Data Mart.

2. Bottom-Up approach
Awalnya dibangun beberapa Data Mart, belakangan beberapa Data Mart yang mempunyai Conform Dimension bisa dirangkai menggunakan
jalur bersama yang disebut Arsitektur Data Warehouse BUS (Ralph Kimball).

(Mengenai Arsitektur Data Warehouse selengkapnya akan dibuat dalam sesion tersendiri.)

Beberapa keuntungan dalam membangun Data Mart lebih dulu dibanding langsung membangun Data Warehouse:
- Waktu yang diperlukan untuk membangun Data Mart adalah lebih sedikit.
- Volume Data pada Data Mart lebih sedikit
- Waktu Query lebih cepat
- Biaya membangun Data Mart lebih murah.

Reff:
BI Assorted, http://www.keysoft.co.in/articledisp.aspx?ArticleId=17
Exforsys Inc, http://www.exforsys.com/tutorials/msas/data-warehouse-design-kimball-vs-inmon.html

Awalnya ODS dipakai sebagai titik integrasi dari beberapa sistem operasional. Hal ini penting untuk Legacy System yang dikembangkan secara independen antara bagian satu dengan yang lain. Bank sebagai contoh, biasanya mempunyai beberapa Sub System yang saling independen untuk mendukung beberapa fungsi bisnis yang berbeda, misalnya ada Core Banking, ATM System, dan Credit Card System. Untuk mengintegrasikan Saldo dari beberapa Sub sytem yang terpisah tersebut, Bank bisa membangun ODS.

ODS seperti ini yang mendukung sistem operasional dengan adanya operasi Access dan Update, Maka ODS ini
seharusnya ditempatkan diluar Data Warehouse. Karena itu struktur sistem nya disesuaikan dengan kebutuhan
operasional namun performannya akan sulit untuk memenuhi kebutuhan sebagai bagian dari sistem Desicion Support.
ODS masih dipertimbangkan sebagai sistem yang terpisah dari Data Warehouse karena ODS berlandaskan “Operasional” data.
menurut Inmon, posisi ODS terhadap Data Warehouse adalah sebagai berikut:

ODS diumpan data dari Legacy System. Dalam ODS data tersebut ditransformasikan dan diintegrasikan. Setelah batas waktu yang ditentukan tercapai (misalkan sehari atau Sebulan), data diteruskan dari ODS ke Data Warehouse. ODS sangat berguna untuk aplikasi perusahaan yang mission-critical. Fokus keputusan yang didasarkan pada ODS adalah keputusan yang bersifat sangat segera, sedangkan fokus keputusan yang didasarkan pada Data Warehouse bersifat agak lama atau lama sekali.

ODS vs Data Warehouse
Sekilas ODS memang mirip dengan Data warehouse jika dilihat struktur dan isinya. baik ODS maupun Data Warehouse adalah Subject-Oriented
dan Integrated. Namun ODS mengandung Volatile Data, sementara Data Warehouse mengandung Nonvolatile Data, artinya Data pada ODS
bisa diupdate sementara Data dalam Data Warehouse tidak boleh diupdate. Perbedaan penting yang lain adalah ODS hanya berisi data aktual
kalaupun ada data sejarah hanya dalam rentang waktu yang kecil, sementara pada Data Warehouse mengandung baik data aktual maupun data sejarah dengan rentang waktu yang besar misalkan 5th atau lebih.
Perbedaan yang lain adalah ODS hanya mengandung Detail Data sedang Data Warehouse mengandung baik Detail data maupun Summary Data.

Jenis-jenis ODS
ODS dapat dikelompokkan menjadi tiga berdasarkan waktu Update nya, sebagai berikut:

ODS Class-1
ODS diupdate secara sinkron dengan Legacy system. Ketika pada Legacy system terjadi Update maka dalam beberapa detik kemudian Update diteruskan pada ODS. Untuk kepentingan praktis kedua sistem menggunakan mekanisme Lock Step satu dengan yang lain.
Perbedaan waktu antara dua atau tiga detik harusnya tidak menjadi perbedaan pada keputusan bisnis yang akan diambil.

ODS Class-2
Biasa menggunakan teknik yang disebut ‘store and forward approach’. Update yang terjadi di Legacy sytem dan hasilnya dikirimkan pada file terpisah, secara periodik setiap jam file tersebut diteruskan ke ODS.
Kedua sistem yakni ODS dan Data warehouse dalam kondisi tidak singkron untuk satu atau dua jam.

ODS Class-3
Pada tipe ini juga digunakan teknik ‘Store and Foward’ seperti pada ODS Class-2 namun baru bisa selesai sampai ke ODS dalam
basis 24 jam atau lebih.

ODS Class-2 dan ODS Class-3 adalah yang umum dipakai. ODS Class-1 sangat jarang dipakai karena dua alasan
Kasus bisnis yang menggunakan ODS Class-1 sangat tidak lazim dan biaya teknologi dan operasional untuk ODS Class-1
sangat mahal. Sebaliknya kasus bisnis untuk ODS Class-2 dan ODS Class-3 sangat umum dan dapat didukung dengan
teknologi yang standard.

Memindah ODS
Saat ini teknologi Hardware dan Software yang mendukung Data Warehousing telah berkembang pesat dan tidak lagi ada masalah untuk menyimpan data sejarah level atomic, bahkan kita telah mampu melakukan proses Extract dan Cleansing data dengan cara yang amat cepat.
Pada saat ini adalah hal yang biasa untuk membicarakan multiterabyte Data Warehouse, bahkan para Consultan telah berani bicara mengenai Petabyte (1000 Terabyte) Data Warehouse yang sudah didepan mata. Dengan dukungan teknologi saat ini, mengapa kita harus menempatkan ODS
sebagai sistem yang terpisah? mengapa kita tidak menempatkan ODS di depan? menjadi bagian Data Warehouse itu sendiri?

Membawa ODS yang berorientasi sebagai Decision Support ke dalam framework Data Warehouse akan menyelesaikan beberapa
masalah. Dengan demikian kita hanya perlu fokus pada satu alur proses Data Extract. Pemikiran kita tidak perlu terbelah jika kita tetap menerima konsep ODS yang volatile, atau ODS yang tanpa data sejarah, atau ODS yang tidak mendukung peningkatan kinerja Aggregation.
Teknologi kita telah banyak kemajuan dalam beberapa tahun terakhir. Kita telah tahu bagaimana bisa mengambil data transaksi pada level atomic, dan menaruhnya dalam framework Dimensional, dan secara serempak membangun sejarah detail transaksi, dan pada waktu yang sama membangun
periodik snapshot secara berurutan yang memungkinkan kita untuk menelusuri enterprise yang komplek lintas waktu.

Dengan membawa ODS kedalam lingkungan Data Warehouse, kita akan membuatnya lebih bermanfaat baik untuk Clerk, Executive dan Analyst dan kita hanya perlu membuat satu saja Extract System. ODS yang baru secara sederhana ditunjukkan pada gambar berikut:

New ODS

Menurut Kimball, sebenarnya ada definisi mengenai ODS perlu diperbarui, dan secara mendasar mempunyai fungsi yang berbeda.
Pada definisi yang baru ini, fungsi ODS telah berubah menjadi semacam Desicion Support yang dapat di access baik oleh Clerk ataupun oleh Executive.
Dalam hal ini ODS mengandung detail data yang telah terintegrasi, sehingga kita membangunnya untuk mendukung layer terendah dari Data Warehouse. Jadi ODS benar-benar bagian dari Data Warehouse yang tidak terpisahkan. Secara sederhana dikatakan ODS adalah “front edge” dari Data Warehouse.

Definisi ODS menurut Kimball:
The ODS should be a subject-oriented, integrated, frequently updated store of detailed data to support transaction systems with integrated data.

Atomic level dari detail data operasional dalam Data Warehouse mempunyai karakteristik sbb.:

Subject oriented.
Seperti pada Data Warehouse yang sebelumnya, ODS juga diorganisasikan untuk bisnis proses tertentu seperti
Orders, Claim, Activity, Policy, Claim, atau Shipment.

Integrated.
ODS menjembadani antar Subject dan memberikan pandangan bisnis yang menyeluruh daripada pandangan bisnis yang sempit.

Frequently augmented.
Data pada ODS secara konstan akan selalu bertambah. karakteristik ini secara signifikan meninggalkan definisi awal mengenai ODS yang berarti ODS adalah volatile, sebagai contoh data ODS secara konstan akan di ditimpa dengan data baru, dan struktur datanya secara konstan juga akan berubah.
karakteristik ‘Frequently augmented’ juga bertolak belakang dengan definisi awal ODS dari Inmon and Imhoff’s bahwa ODS mengandung hanya ‘current valued data’ atau hanya mengandung data yang aktual.

Sits within the full data warehouse framework of historical and summarized data.
ODS sepenuhnya ditempatkan dalam framework sejarah dan rangkuman dari Data Warehouse. Data Warehouse mengandung data rangkuman bulanan dari detail transaksi yang selalu ditambahkan, aliran masuk data atomic ini juga menyebabkan “current rolling month” yang khusus, maksudnya
khusus pada akhir bulan data bulanan aktual akan digulung. Dalam banyak kasus pada saat tanggal terakhir suatu bulan dicapai, maka “current rolling month” tersebut menjadi member yang paling baru dari bulan standard dalam time-series selanjutnya “current rolling month” yang baru akan dibuat.

Naturally supports a collective view of data.
Kita sekarang telah melihat bagamana data level atomic dapat memberikan view kolektif pada Executive yang dapat melihat Account Balance Customer secara keseluruhan. Executive juga dapat segera menghubungkan view kolektif Customer bulan yang lalu (Lewat Time-Series) dan meliputi juga kelas beberapa customer (lewat aggregasi Data warehouse).

Organized for rapid updating directly from the legacy system.
Industri Data Extraction dan Data Cleansing telah menempuh perjalanan yang panjang dalam beberapa tahun terakhir, kita telah dapat mengalirkan data dari Legacy System ke step data cleansing dan step integrasi lalu menaruhnya pada level atomic Data Warehouse. pengelompokan awal ODS sbb.:

Class-1 : upload mendekati real-time
Class-2 : upload setiap Jam
Class-3 : upload sehari sekali

Pengelompokan kelas-kelas ODS ini, seperti yang dijelaskan dalam “Building Data Store” adalah masih valid namun arsitekturnya berbeda dalam hal mengalirkan Data Extract yang menjadi jauh kurang menarik dibandingkan yang biasanya. Saat ini kemampuan untuk upload data sesering mungkin lebih
tergantung pada menunggu operasional sistem untuk memberikan data yang diperlukan daripada karena waktu kalkulasi atau bandwith yang terbatas dalam mengalirkan data.

Should be organized around a star join schema design.
Inmon, Imhoff dan Battas merekomendasikan data model Star-Schema sebagai deskripsi paling mendasar dari suatu desain dari data yang ada di ODS.
Kimball dengan antusias setuju. Star-Schema atau dimensional model adalah data model yang paling sesuai untuk memberikan user kemampuan pemahaman dan performan tinggi yang bisa diperhitungkan, baik pada atomic ataupun data ringkasan.

Contains all of the text and numbers required to describe low-level transactions.
ODS mengandung semua text dan angka yang diperlukan untuk menjelaskan data transaksi di level rendah.
Bagaimanapun juga, ODS mungkin perlu mengandung data tambahan referensi kebelakang untuk access ke Legacy System yang memungkinkan dibukanya Real-Time Link ke Legacy System lewat suatu Terminal atau interface yang berdasarkan transaksi.
Ini adalah aspek yang menarik dari definisi awal ODS, dan hal itu sedikit banyak secara langsung jika data transaksi level rendah
dialirkan keluar dari Legacy System ke dalam bagian level Atomic dari Data Warehouse.

Secara teknik ini adalah Operational Key, seperti Nomor Invoice, dan Nomor baris, yang akan dipertahankan dalam semua alur data sampai kedalam atomic level Data Warehouse. Sehingga aplikasi dapat mengambil Operational Key tersebut dan bisa terhubung dengan sukses kebelakang ke interface
Legacy System.

Supported by extensive metadata.
Mendukung Metadata yang luas. Metadata diperlukan untuk menjelaskan dan menampilkan arti suatu data ke End-User lewat Query atau Reporting Tool, seperti halnya menjelaskan suatu hasil Extract “AUDIT” pada isi Data Warehouse.

Jika anda telah mempunyai ODS atau baru merencanakan untuk membangun ODS, perlu diuji dengan hati-hati untuk menentukan peruntukannya.
Jika ODS tsb. berlaku sebagai operational system atau real-time Role, maka ODS tsb benar-benar bagian dari Operational System dan perlu ditempatkan pada lingkungan operatioanal System. Sebaliknya jika ODS tsb. menyediakan Reporting atau mempunyai kemampuan untuk Decision Support,
ODS tsb. harusnya menjadi bagian yang terpadu dengan level atomic Data Warehouse , dan menyesuaikan diri dengan arsitektur Data Warehouse Bus.

Pada akhirnya, Jika anda berkata pada diri sendiri bahwa organisasi anda tidak ada kepentingan untuk menyimpan semua transaksi detail karena management anda hanya melihat pada data ringkasan level tinggi, maka anda perlu untuk melihat lebih luas dan mendengar apa yang terjadi di dunia luar.
Dewasa ini kita sedang menuju ke era one-to-one marketing dimana organisasi mencari pemahaman dan menanggapi secara detail setiap perilaku individual Customer.

Bank perlu mengetahui dengan tepat siapa di ATM antara pukul 5 sampai 6 sore, apa transaksi yang dilakukan, dan bagaimana pola tersebut mempunyai kaitan dengan berbagai program insentif bank di tahun ini.
Kasus lain, seorang marketing sebuah toko scaner elektronik melakukan kupon promosi, ia siap untuk mencetak kupon pada toko elektronik anda membuat daftar untuk menanggapi pada apa yang ada pada keranjang belanja anda dan apa yang telah anda beli pada saat belanja terakhir.
Untuk melakukan ini semua, organisasi perlu data semua transaksi detail baik yang aktual ataupun yg sudah menjadi sejarah.

Reff:
Inmon, Bill, The Operational Data Store, InfoDB February 1995
Kimball, Ralph, Relocating the ODS Moving the Operational Data Store Will Solve a Number of Problems,
DBMSOnline, December 1997.
Kimball, Ralph, Jhon Wiley & Sons, Inc.,The Data Warehouse Lifecycle Toolkit, New York- USA,2000

Slice
Dalam terminologi Multidimensional Analysis, Slice digunakan untuk mendefinisikan sebuah member atau sekumpulan member
yang dipisahkan (dari ALL Dimension-Dimension lain) lalu dievaluasi melintang pada semua Dimension.
Sebuah member dari suatu Dimension berarti suatu nilai dalam sebuah level pada Dimension tersebut.

Untuk lebih memahami konsep Slice perhatikan contoh dibawah ini:
Misalkan kita hanya mempunyai tiga Dimension dengan nama Poduct, Store, dan Date dalam suatu Dimensional Model yang
sederhana. Kita hanya mempunyai satu table Fact yang dinamakan Sales.
Asumsikan bahwa kita memisahkan tiga member dari Product Dimension, ketiga member ini adalah Soda, Milk dan Juice.
hal ini ditampilkan pada gambar dibawah:

Jika kita menjumlahkan penjualan ketiga member tersebut (Soda, Milk, Juice) dengan fungsi SUM untuk ALL Stores dan ALL Dates
berseberangan satu atau lebih Member dari satu Dimension (Dimension Product), maka konsep inilah yang disebut Slicing.
Tanda panah pada gambar diatasnya menunjukkan bahwa SUM meliputi ALL Stores dan ALL Dates.

Slice pada Product Dimension ini membuat kita dapat memilih pada member mana kita akan fokus (dalam hal ini kita
fokus pada member Soda, Milk, dan Juice) dan berseberangan dengan Dimension yang lain (Store dan Date).

Dice
Konsep Dicing berarti kita menaruh beberapa Member dari suatu Dimension pada suatu Sumbu koordinat lalu meletakkan
beberapa Member dari Dimension lain pada sumbu yang lain. Dengan cara ini akan memungkinkan melihat hubungan antar Member dari Dimension-Dimension yang berbeda.

Dicing adalah analisa hubungan antar Dimension-Dimension yang berbeda atau Member-Member Dimension tersebut. Gambar dibawah menunjukkan contoh Dicing.

Dice

Pada gambar diatas kita dapat lihat beberapa Members pada Dimension STORE ditempatkan secara vertical salah satu sumbu.
Member tersebut adalah CA, OR, dan LA. Dengan cara yang sama beberapa Member pada Dimension DATE ditempatkan secara horisontal.
Dengan cara ini kita dapat melihat hubungan antar members dari Dimension yang berbeda, lebih tepatnya kita dapat melihat hubungan antara CA dengan tanggal 1/1/09, 2/1/09, 3/1/09 dan sebaliknya.

Selanjutnya pada gambar berikut kita dapat melihat hubungan antara Members dari Dimension STORE dan PRODUCT.

Dice

Contoh analisa yang dapat dilakukan dari gambar diatas adalah sebagai berikut:
- Berapa kontribusi masing-masing toko pada total penjualan
untuk setiap Product (Soda, Milk, dan Juice)?
- Berapa kontribusi Product tertentu pada total penjualan untuk
setiap lokasi Toko?

Pivoting
Pivoting pada Multidimensional Modeling berarti menukarkan Baris dengan Kolom dan sebaliknya. Gambar berikut menunjukkan contoh Pivoting.

Pada gambar diatas kita menukarkan Dimension STORE pada Baris dengan PRODUCT pada Kolom.
Ini adalah cara yang cepat dan sederhana untuk melihat dengan perspektif yang berbeda.

Drill-Down dan Drill-Up
Drilling dalam Multidimensional terminologi berarti perpindahan dari satu level Hierarchy ke level yang lain. Dengan kata lain Drill-Down dapat didefinisikan sebagai kemampuan untuk melihat informasi pada struktur Hierarchy dibawahnya.

Pada contoh gambar dibwah ditunjukkan Drill-Down pada tiga level hierarchy sederhana dalam Dimension PRODUCT.
Hierarchy tersebut adalah :

‘GROUP CASS’–>’GROUP’–>’PRODUCT’.

Pada akhirnya dengan melakukan Drill-Down pada attribute GROUP, kita akan sampai pada level terendah dari Dimension PRODUCT (yang mana mmerupakan Product item) seperti ditunjukkan pada gambar dibawah:

Drill-Down

Drill-Across
Drill-Across adalah suatu cara dimana kita dapat Drill dari satu Dimension ke Dimension yang lain. Fungsi ini umumnya digunakan pada ROLAP, Pada gambar dibawah dapat dilihat contoh dari Driill-Across dari Dimension STORE CA ke Dimension PRODUCT.

Drill-Across

Pada gambar diatas dapat kita lihat Drill-Across dari STORE CA ke Dimension PRODUCT. Pada tabel pertama menunjukkan
Penjualan dalam Dimension STORE dari tiga negara bagian, dan kita akan fokus hanya pada CA (California).
Dengan fungsi Drill-Across ke Dimension PRODUCT kita bisa melihat lebih detail tentang product mana saja yang menentukan penjualan pada STORE CA.

Roll-Up and Roll-Down
Roll-Up and Roll-Down adalag fungsi OLAP yang memberikan aggregate lebih tinggi atau lebih rendah dari seluruh Dimension pada lebel Hierarchy yang diberikan. Pada contoh gambar dibawah kita Roll-Down Dimension PRODUCT dari level 3 ke level 2 and ke level 1.
hal ini bisa diselesaikan lewat Hierarchy PRODUCT level:

GROUP CLASS–>GROUP–>PRODUCT.

Roll-Up dan Roll-Down

Konsep Roll-Down mirip dengan Drill-Down, dan Roll-Up adalah kebalikan dari Roll-Down. Juga bisa dikatakan Konsep Roll-Up
mirip dengan Drill-Up.

Reff:
IBM, Dimensional Modeling: In a Business Intelligence Environment, RedBook, 2006

OLAP menyediakan cara untuk menampilkan data Multi Dimensional yang ada dalam Data Mart atau Data Warehouse, dengan OLAP dapat dibuat Cube yang mengorganisasikan data dan membuat summary data untuk query yang effisien.

Karakteristik OLAP
- Menggunakan teknik analisa data Multidimensional
- Menyediakan dukungan database tingkat lanjut
- Menyediakan cara pakai yang mudah dan User Interface yang
mudah difahami.
- Mendukung arsitektur Client/Server

OLAP Features

Beberapa produk OLAP secara logika adalah sama, kesamaan tersebut antara lain dalam hal-hal berikut:
- Berdasarkan Dimensional
- Pre-Aggregate untuk meningkatkan performance dan
- Mendukung bahasa analisa data tingkat lanjut

Sebenarnya secara fisik ada perbedaan pada cara menyimpan Cube dalam Data Warehouse, dan dipasaran dikelompokkan menjadi seperti berikut:

MOLAP
Multidimensional OLAP, Data disimpan dalam bentuk Multidimensional Database.

Pros:
– Performance hebat, karena MOLAP memang dibangun
untuk pengambilan data yang cepat, dan optimal untuk
operasi Slicing dan Dicing.
– Dapat membentuk kalkulasi yang komplek dan cepat.
Semua kalkulasi telah dihitung saat Cube dibentuk.

Cons:
– Jumlah volume data yang dapat ditangani terbatas. Karena
semua kalkulasi telah dihitung saat Cube dibentuk maka
untuk menyimpan hasil kalkulasi tersebut diperlukan
volume data yang besar dalam Cube nya sendiri.
– Diperlukan investasi tambahan karena teknologi MOLAP
Cube seringkali belum dimiliki oleh organisasi, dengan
kata lain untuk mengadopsi teknologi MOLAP ada peluang
untuk menambah investasi tenaga dan biaya.

ROLAP
Relational OLAP, menggunakan Relational Database baik untuk menyimpan Detail data maupun untuk menyimpan Aggregate nya. Memanage pembuatan dan perawatan Aggregate.

Pros:
– Dapat menangani jumbalh volume data yang sangat besar,
batasan ukuran volume data yang ditangani pada
teknologi ROLAP adalah batas dari volume dari Relational
Database yang dipakai. Dengan kata lain pada ROLAP
sendiri tidak ada batasan volume data.
– Dapat memanfaatkan fungsi-fungsi yang ada pada
Relational Database yang dipakai.

Cons:
– Performance dapat lambat, karena setiap ROLAP report
pada dasarnya adalah SQL Query pada Relational Database,
waktu Query dapat lebih lama jika volume data semakin
besar.
– Fungsi SQL yang terbatas, karena teknologi ROLAP
terutama tergantung pada pembentukan statement Query
pada Relational Database, dan tidak semua kebutuhan
dapat terpenuhi dengan SQL Statement. ROLAP vendor
telah mengantisipasi resiko ini dengan cara membuat Tool
out-of-the-box untuk fungsi-fungsi yang kompleks bahkan
memungkinkan user untuk mendefinisikan fungsi-fungsi
yang dibutuhkannya sendiri.

HOLAP
Hybrid OLAP, Menggabungkan kedua teknologi diatas. HOLAP menggunakan Relational Database untuk menyimpan Detail data dan menggunakan Multidimensional Database untuk menyimpan Aggregate nya.

HOLAP menggabungkan kelebihan-kelebihan yang ada pada MOLAP dan ROLAP.
HOLAP juga memanfaatkan teknologi MOLAP cube untuk mendapatkan performance yang lebih cepat.
Jika dibutuhkan informasi di level detail, HOLAP dapat ‘Drill-through” dari Cube masuk kedalam Relational Database yang mendasarinya.

OLAP Comparizon

Reff:
-Ponniah, Paulraj, Data Warehousing Fundamental,New
York-USA,2001.
Jhon Wiley & Sons, Inc.
-Thomsen, Erik, 1999. Microsoft OLAP Solution, New York-USA,
Jhon Wiley & Sons, Inc.
-Peterson, Timothy, Microsoft OLAP, Sams Publishing, USA, 2000

Setiap DM terdiri atas satu tabel dengan banyak Foreign Key yang disebut Facs Table dan satu set tabel yang lebih kecil yang disebut Dimension Table, setiap Dimension Table mempunyai satu bagian Primary Key yang terhubung dengan tepat pada salah satu Foreign Key dari beberapa Key pada tabel Facs tersebut. (lihat gambar dibawah):

Karakteristik pada gambar tersebut yang seperti struktur bintang biasa disebut dengan Star-Schema. Dengan demikian dapat dikatakan bahwa Star-Schema adalah teknik Data Modeling yang digunakan untuk memetakan Multi Dimensional Diecission Support pada suatu database relasional.

Dengan menggunakan Star-Schema maka implementasi suatu Model untuk analisa Multidimensional Data menjadi mudah,
selain itu operasi database dengan struktur relasional juga masih dimungkinkan.

Hubungan antara Fact Table dan Dimension Table tidak lagi menggunakan Natural Key atau Key yang dipakai di Legacy sistem, tetapi menggunakan Key Pengganti atau biasa disebut Surrogate Key. Alasannya antara lain:
Karena Data pada Data Warehouse tidak boleh di update (Non Volatile) sedangkan Key pada Legacy karena tuntutan bisnis bisa saja suatu saat berubah.

Untuk menjaga performance yang tinggi Surrogate Key dibuat sesederhana mungkin yaitu cuma satu field dan bertipe Numeric dari Running Number yang dihitung dari ETL Program atau dari tipe data pada Data Base nya sendiri.

Komponen-komponent Star-Schema:
1. Fact
2. Dimensions
3. Attributes
4. Attribute Hierarchie
5. Granularity

Penjelasan masing-masing komponen Star-Schema diatas adalah sebagai berikut:

1. Fact
Fact adalah suatu angka dari pengukuran yang
menunjukkan aspek tertentu dari suatu bisnis atau suatu
aktivtas .
Fact Table berisi beberapa fakta yang terhubung dengan
masing-masing Dimension nya.
Fact dapat berupa nilai yang telah ada atau baru
diturunkan pada saat Run-time.

2.Dimensions
Dimension adalah karakteristik suatu ukuran yang
menyediakan tambahan cara melihat suatu fakta yang telah
diberikan pada Fact Table. Dimension disimpan pada Dimension
Table.

3. Attributes
Setiap tabel dimensi mempunyai Attributes. Attributes sering
dipakai pada operasi Search, Filter, atau Grouping dari suatu
Fact. Dimensions menyediakan karakteristik deskriptif (uraian)
tentang Fact lewat Attribut nya.

Beberapa contoh Attributes:
Nama Dimension : Location
Keterangan : Segala sesuatu yang menjelaskan
tentang lokasi suatu tempat
Attributs : Propinsi, Kabupaten, Kota,Toko

Nama Dimension : Product
Keterangan : Segala sesuatu yang menjelaskan tentang
produk yang terjual
Attributs : Tipe Produk, Merek, Paket, Kemasan,
Warna, Ukuran, dsb.

Nama Dimension : Time
Keterangan : Segala sesuatu yang menjelaskan tentang
waktu penjualan.
Attributs : Tahun, Kuartal, Bulan, Minggu, Hari, dsb.

4. Attribute Hierarchies
Attributes pada suatu Dimension dapat diurutkan dengan
definisi yang baik dalam suatu Attribute Hierarchies.
Attribute Hierarchies menyediakan Data dengan organisasi
Top-Down yang terutama berguna untuk:
– Aggregation
– Drill-Down/Roll-up Data Analysis

5. Granularity
Granularity adalah salah satu aspek terpenting dalam desain
Data Waehouse karena menentukan volume data
yang akan disimpan dalam Data Warehouse dan menentukan
kedalam detail Query yang bisa dijalankan.
Secara ekstrem ada Lowest Grain (Grain terendah) dan
Highest Grain (Grain tertinggi).
Lowest Grain menyimpan transaksi di level detail (Atomic
Transaction) sedangkan Highest Grain menyimpan data hanya
dilevel Enterprise atau level Perusahaan (Summary
Transaction)
Level dari Granularity disimpan pada Hirarchy suatu Dimension.

Reff:

Kimbal, Ralph, 2000, The Data Warehouse Lifecycle Toolkit, New York- USA, Jhon Wiley & Sons, Inc

Todman, Chris.,Designing A Data warehouse, Prentice-Hall, Inc., USA, 2001

Chuck-Ballard, Dirk-Herreman, Don-Schau, Rhonda-Bell, Eunsaeng-Kim, Ann-Valencic, Data Modeling Techniques for Data Warehousing,IBM, 1998

Bill Inmon – Corporate Information Factory (CIF)
1. Pendekatan : Top down
Buatlah design dengan sangat matang dan lengkkap terlebih
dahulu, sebisa mungkin mengakomodasi kebutuhan user baik
sekarang, maupun nanti di masa mendatang, baru kemudian
nanti dibangun data warehouse.
Dikalangan developer desain Inmon sering disebut dengan
“big bang” approach.
2. Data marts bersumber dari data warehouse
Setelah data warehouse terbangun, data marts yang ada
pada departemen-departemen mengambil sumber informasi
dari satu (dan satu-satunya) Data Warehouse tersebut.
3. Pada Data Warehouse Informasi tersimpan dalam bentuk
relasional 3rd Normal Form.
4. Lebih berorientasi pada proses pemodelan data (data
modelling)
5. Aspek technical lebih tinggi, membutuhkan background IT
yang kuat untuk melakukan pemodelan data.
Dengan demikian, bagian IT berperan besar sebagai
pembangun dan penyedia (provider) data warehouse.

Reff: Building the Data Warehouse

Ralph Kimball – Data Warehouse Bus
1. Pendekatan : Bottom up
Bangun Data Mart pada departemen-departemen yang
memiliki inisiatif dan membutuhkan, kemudian lakukan proses
integrasi data mart jika diperlukan.
2. Data warehouse merupakan kumpulan dari banyak data mart
4. Informasi tersimpan dalam bentuk Multidimensional
(Denormalisasi)
5. Lebih berorientasi pada pendefinisian interaksi data pada
suatu / antar proses bisnis
6. Pemodelan multidimensional relatif lebih mudah dimengerti
oleh End User, sehingga End User dapat berperan lebih banyak
dalam proses pemodelan data. Dengan demikian end user dan
bagian IT memiliki peran yang seimbang.

Reff: The Data Warehouse Toolkit

Kedua desian tersebut sebenarnya tidak ada yang salah atau benar,apalagi menjadi suatu pertentangan Inmon vs Kimball karena keduanya mempunyai filosofi yang berbeda tentang Data Warehouse.

Pada kenyataannya desain Ralph Kimball yang banyak digunakan karena sebagian pembangunan besar Data Warehouse dimulai dari satu Departemen dan dilanjutkan ke Departemen yang lain karenanya hal ini berarti membangun Data Mart. Jika kemudian dibangun beberapa Data Mart lagi berarti sistem telah berkembang menjadi Data Warehouse.

Lebih jauh lagi Kimball juga mengusulkan menggunakan arsitektur Data Warehouse dengan Bus Architecture.
Arsitektur ini terdiri dari:
- Staging Data Area
- Data Warehouse Bus
Data Warehouse Bus itu sendiri yang terdiri dari beberapa
atomic Data Marts, beberapa aggregated Data Marts dan
personal Data Mart, namun tidak ada komponen single atau
centralize Data warehouse.

(Mengenai Data Warehouse Bus ini akan dibahas di sesi tersendiri)

Pada umumnya Data Warehouse berisi data sejarah yang diturunkan dari data transaksi dan beberapa data dari sumber data yang lain.

Dengan Data Warehouse maka Organisasi bisa mendapatkan data yang sudah terkonsolidasi dari berbagai sumber data.

William Harvey Inmon atau biasa dipanggil Bill Inmon pada tahun 1991 dalam bukunya “Building the Data Warehouse”
mendefinisikan Data Warehouse sbb.:

“A data warehouse is a subject-oriented, integrated,
timevariant, and nonvolatile collection of data
in support of management’s decision-making
process.”

Subject-oriented:
- Data di kumpulkan berdasarkan subjek utama, misalnya
Customer, Product atau Sales.
- Data Model dan analisa diutamakan untuk pengambil
keputusan bukan untuk proses transaksi sehari-hari.
- Menyediakan cara yang sederhana dan ringkas untuk
menampilkan data sekitar subjek tertentu dengan cara
mengeluarkan data yang tidak berguna dalam proses
pengambilan keputusan.

Integrated:
- Dibangun dari integrasi berbagai macam sumber data
misalnya Relational Database, Flat Files, Online
Tansaction record, dsb.
- Menggunakan teknologi Data Cleansing dan Data
Integration. Tujuannya:
- Memastikan konsistensi Naming Convention,
Encoding Structure, Ukuran attributes. dsb.
diantara sumber data yang berbeda-beda.
- Ketika data dimasukkan ke Data
Warehouse, data tesebut telah dikonversikan.

Time Variant:
- Rentang waktu data untuk Data Warehouse pasti lebih
panjang jika dibandingkan dengan sistem operasional
- Data Sistim Operasional : Data saat ini
- Data Data Warehouse : Menyediakan informasi
dari perspektif sejarah misal 5 s/d 10 tahun
- Setiap struktur Key dalam Data Warehouse selalu
mengandung elemen Time secara implisit atau explisit
- Namun pada Key data operasional mungkin tidak
mengandung elemen Time.

Non Volatile:
- Artinya begitu data masuk ke Data Warehouse
seharusnya Data tidak boleh berubah lagi.
- Secara fisik data pada Data Warehouse disimpan
terpisah dari operasional sistem.
- Operasi Update tidak pernah terjadi pada lingkungan
data Warehouse, karena
- Tidak perlu melakukan proses transaksi, Recovery,
dan mekanisme kontrol proses simultan.
- Hanya memerlukan dua operasi proses Data yaitu
Data Loading dan Data Retrieving.

Elemen-elemen dasar Data Warehouse

Source System
Operasional sistem yang berfungsi mencatat transaksi dari
suatu bisnis. Source System biasa disebut juga sebagai
Legacy System.

Data Staging Area
Tempat penyimpanan data sementara, untuk melakukan
proses Clean, Transform, Combine, Deduplicate,
Household, archive, dan menyiapkan sumber data untuk
digunakan Data Warehouse.

Staging Area tidak diperuntukkan sebagai sumber data
untuk reporting karena datanya masih kotor dan bersifat
sementara.

Presentation Server
Target mesin yang secara fisik adalah mesin dimana data
dari Data Warehouse di organisasikan dan disimpan untuk
dilakukan query oleh End User, Reporting dan aplikasi yang
lain. Disini data disimpan dengan framework Dimmensional.

Jika menggunakan Relational Database maka tabel akan
diorganisasikan dalam bentuk Star-Schema, namun
jika tidak menggunakan Relational Database maka akan
disimpan dalam bentuk OLAP.
(mengenai OLAP akan dibahas pada sesi tersendiri)

Dimensional Model
Data Modeling yang khusus dipakai pada Data Warehouse,
sebagai alternatif lain dari E/R Modeling yang biasanya
dipakai pada sistem transaksional.

Business Process
Dalam terminologi disini bukanlah Business Process seperti
pada transaksional sistem, tetapi lebih tepat maksudnya
adalah mengelompokkan sumber data menurut kesamaan
temanya. Misalnya Finance, Marketing, Production. etc.

Nantinya setiap Business Process akan diimplementasikan
sebagai Data Marts.

Data Mart
Potongan secara logika dari Data Warehouse secara
keseluruhan.

Data Mart bisa juga dilihat sebagai potongan secara logika
dari data Warehouse terhadap suatu Business Process
tertentu.
(mengenai Data Mart, akan dibahas pada sesi tersendiri)

Data Warehouse
Adalah sumber data yang bisa di Query dalam suatu
perusahaan. Sebenarnya Data Warehouse adalah
gabungan dari beberapa Data Marts.

Operational Data Store
Pada awalnya ODS adalah titik integrasi dari berbagai
operasional sistem. Karena ODS juga mendukung access
operasional dan bisa di update maka ODS seharusnya
ditempatkan diluar Data Warehouse.

Pada akhirnya fungsi ODS juga berkembang menjadi
semacam Desicision Support karena ODS mengandung
detail data yang telah terintegrasi dari berbagai sumber
Data.

OLAP
Disebut juga sebagai Multidimensional Database (MDDB).
OLAP sengaja dirancang untuk memudahkan dan
mempercepat query yang dilakukan pada MDDB.

Karakteristik dan sifat OLAP sangat berbeda dengan OLTP
karena memang mempunyai tugas dan fungsi yang
berbeda.

ROLAP
Relational OLAP.

MOLAP
Multidimensional OLAP

End User Application
Sekumpulan Tool yang bisa melakukan Query, Analisa
Data, dan menampilkan informasi untuk mendukung
kepentingan Bisnis.

Paling tidak Tool ini juga dilengkapi dengan kemampuan
untuk akses Data, fungsi Spreatsheet, fungsi grafik, dan
ada fasilitas untuk menampilkan prompt dan
menyederhanakan tampilan screen pada End User.

End User Data Access Tool
Sebagai Client dari Data Warehouse. Pada Relational Data
Warehouse, Client dapat mengirimkan SQL Request
ke Server.

Secepatnya End User Data Access Tool akan selesai pada
SQL Session dan kembali untuk menampilkan pada screen
Data dari suatu Report, Grafik, atau yang lebih tinggi
seperti form suatu analisa pada User.

End User Data Access Tool dapat saja sederhana seperti
Ad-Hoc Query Tool atau bisa juga bisa komplex
seperti Data Mining yang canggih atau aplikasi modeling.

Ad-Hoc Query Tool
End User Data Access Tool yang dibuat khusus sehingga
memungkinkan User untuk membuat Query sendiri secara
langsung dengan cara memanipulasi Relational Tables dan
Join-join nya.

Dipasaran biasanya Ad-Hoc Query Tool dipaket menjadi
satu dengan Reporting Tool.

Modeling Application
Data Warehouse Client yang canggih dengan kemampuan
analytic yang dapat merubah bentuk atau menjadikan
intisari dari output Data Warehouse.

Modeling ini termasuk didalamnya adalah:
- Forecasting Model, yang berusaha memperkirakan masa
depan
- Behaviour Scoring Model, yang dapat mengklasifikasikan
perilaku belanja Customer
- Allocation Model, yang mengambil data Cost dari Data
Warehouse lalu membagikan Cost tersebut ke semua
poduct Group atau Customer Group.
- Terutama Data Mining Tools.

Meta Data
Semua informasi dalam lingkungan Data Warehouse namun
bukan data itu sendiri, Misalnya informasi mengenai
asal data source dari aplikasi apa, tabel apa, field apa,
formula bisnis bagaimana, dsb. Meta Data perlu dibuatkan
Catalog, diberi Version Stamp, di dokumentasikan dan di
backup.

Beberapa ETL Tool dipasaran ada yang sudah dilengkapi
Meta Data management.

Demikian elemen dasar dari Data Warehouse, masih banyak komponen yang nanti akan di jelaskan pada sesi berikutnya.

Reff:
Kimball, Ralph, 1998, The Data Warehouse Lifecycle Toolkit, Jhon Wiley & Sons, Inc.

Sebenarnya tujuan BI menyangkut dua hal penting:

- Data Integration, yang berarti menarik data dari berbagai sumber data yang terpisah-pisah dalam berbagai format data, dari berbagai Database lalu disimpan pada satu Database dan membuatnya dapat di access dengan mudah dengan cara yang seragam. Database ini biasa disebut dengan Data Warehouse.

– Analysing and Viewing, yang berarti menyediakan cara untuk menampilkan dan melakukan analisa data dengan cara yang baru dan menampilkan informasi yang sebelumnya tersembunyi. Aplikasi untuk keperluan ini biasa disebut dengan BI Application.

Tujuan tersebut telah dikembangkan selama bertahun-tahun. Awalnya tampak seperti alat untuk market research,  untuk mengentahui karakteristik Customer, untuk menemukan pola-pola dalam Pendapatan dan Keuntungan, atau untuk memahami perilaku Customer, namun saat ini tool yang sama juga dipakai untuk melihat berbagai aspek bisnis.

Istilah BI sendiri pertama kalinya diperkenalkan oleh Howard Dresner dari Gartner Group pada tahun 1989 dengan defenisi
sbb.:

“Business Intelligence is a set of concepts and methodologies to improve  decision-making in business through the use of facts and fact-based systems”

Menurutnya BI adalah sekumpulan konsep dan methodologi untuk meningkatkan pengambilan keputusan dalam bisnis dengan cara menggunakan fakta dan sistem yang berdasarkan fakta.

Bahan dasar dari BI adalah semua transaksi individu, dan data diambil dari berbagai sisi bisnis. Dengan BI setiap detail data bisa diambil namun akan disimpan dengan menggunakan struktur data yang baru sehingga detail tersebut dapat di access dari berbagai sudut pandang. Sehingga untuk setiap pertanyaan bisnis BI akan dapat memberikan jawaban secara tepat dan cepat.

BI akan memberikan sudut pandang bisnis dengan detail yang belum pernah ada sebelumnya. Hal itu dapat dicapai dengan cara merestrukturisasi informasi dengan tepat yang dibutuhkan oleh setiap fungsi kerja, apakah fungsi kerja tersebut adalah market research,
quality assurance, general management atau fungsi kerja yang lain.

Fungsi-fungsi BI yang lain adalah;

-BI memungkinkan pebisnis untuk melihat kinerja bisnisnya dari berbagai sudut pandang, tidak hanya dari sisi accounting belaka.
-Untuk mengetahui pola belanja customer
-Untuk mengungkap hubungan antara suatu kejadian dengan kinerja dagang.
-Untuk melihat dampak nyata dari suatu promosi selagi masih berlangsung.
-Untuk mengungkap penipuan dan pemborosan yang tak berguna.
-Untuk melihat suatu problem selagi dibenahi

Singkatnya, BI memungkinkan untuk memanfaatkan nilai yang ada secara detail

Teknologi apa saja yang digunakan BI?

ETL Tool:
Agar data dari berbagai sumber data dapat di access, maka diperlukan teknologi yang bisa connect ke berbagai Database di berbagai platform. Proses ini meliputi Collection, Cleansing, Extraction, Transformation, and Loading, Tool yang menyediakan fungsi-fungsi ini biasa disebut ETL Tool. Ada berbagai macam ETL tool yang tersedia di pasar, tersebar dngan bebagai kelebihan fungsi dengan harga yang beragam juga.

OLAP Engine:
Agar suatu data dapat dilihat dan di analisa dari berbagai sudut pandang, maka data tersebut perlu disimpan dengan struktur multi dimensi, atau yang disebut dengan Multidimensional database. Untuk  mempercepat query dan analisa maka semua relasi data perlu disimpan dalam group-group dari item-item data yang behubungan, disimpan juga Jumlah item yg berhubungan, dan agregasi dari kuantitas data yang  berhubungan. Semua fungsi ini akan ditangani oleh OLAP Engine.
(Lebih jauh mengenai OLAP akan dibahas pada sesi tersendiri)

Query Tool:
Setelah data disimpan dalam Multidimensional Database, untuk menampilkannya diperlukan tool khusus yang dapat melakukan
berbagai query multi dimensi. Tool ini dapat membuat rumusan query multi dimensi yang kompleks dengan cara yang sederhana
tool ini biasa disebut dengan Query Tool. Beberapa produk Query Tool dipasaran telah dilengkapi juga dengan OLAP Browser
bahkan ada yang di paket dengan Reporting Tool.

Reporting Tool:
Pada Multidimensional Database reporting tool yang dipakai juga harus bisa membaca data multi dimensi.
Pada umumnya Reporting Tool bisa dijalankan dengan cara visual desain dan sudah dilengkapi dengan OLAP Browser.
Report dapat diexport dalam berbagai format sperti format CSV,  PDF file atau PPT file untuk keperluan presentasi.
Beberpa Reporting Tool di pasaran bahkan ada yang dilengkapi dengan Distribution Utility dan Schedulling.

Dashboarding Tool:
Informasi yang disampaikan untuk para pengambil keputusan biasanya tidak ditampilkan dalam angka-angka dalam tabel,
namun dalam bentuk grafik-grafik interaktif untuk mempermudah dan mempercepat pengambilan keputusan. Tool yang mempunyai kemampuan ini disebut dengan Dashboarding Tool.
Dashboarding Tool dilengkapi dengan berbagai macam grafik seperti Bar Chart, Pie Chart, Gauge Chart, dll. baik 2D maupun 3D,

Disamping Tool utama yang sudah disebut diatas, sebenarnya masih ada beberapa tool lagi yang biasa dipakai baik oleh BI Developer ataupun oleh BI User. Mengenai hal ini akan dibahas disesi lain.

Reff:
Tiwana, Amrit, 2001. The Essential Guide to Knowledge Management, New York,USA, Prentice Hall
Kimbal, Ralp, 1996, The Data Warehouse Toolkit, New York-USA,  Jhon Wiley & Sons, Inc.