Posted by: Ardijan Abu Hanifah | December 5, 2009

Apakah ODS itu?

Bill Inmon, Caludia Imhoff, dan Greg Battas dalam buku “Building Operational Data Store”, (John Wiley & Sons, 1996), mendefinisikan ODS sebagai ” “subject oriented, integrated, volatile, current valued data store containing only corporate detailed data.” Definisi ini mencermikan kebutuhan nyata pasar akan data operasional yang aktual.

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

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: