Antara Training dan Project

Posted on July 3, 2008

Pada dasarnya antara training IT dengan project IT selalu ada korelasi-nya. Project tanpa ada training untuk personel-personel-nya pasti tidak akan optimal. Dan dengan training bisa muncul project-project baru. Kedua-dua-nya menjadi kekuatan yang saling melengkapi.

Tapi ada satu hal yang membuat saya harus berdiri di tengah-tengahnya, yaitu portfolio. Seorang trainer akan laku kalau dia mempunyai pengalaman di proyek atau di field. Oleh karena itulah saya harus seimbang dalam mengarungi dunia freelance IT ini. Dengan training kemampuan komunikasi dan teknologi kita akan di asah untuk mencoba memberikan yang terbaik terhadap peserta training, sehingga ada kebanggan buat seorang trainer kalau peserta-nya bisa memahami dan dapat meng-implementasi-kan apa yang di ajarkan oleh trainer. Gunanya komunikasi adalah bagaimana agar apa yang kita sampaikan bisa dimengerti oleh peserta dengan bahasa dan gambaran yang kita ciptakan selama pelaksanaan training. Seluruh body language kita akan selalu diperhatikan oleh peserta training, entah itu yang disengaja atau yang tidak disengaja.

Oleh karena itu lah saya berdiri di tengah-tengah-nya ….. :D.
So it’s time to implement project boys….. let’s go.

» Filed Under My Life.. | 2 Comments

Windows Movie Maker dan Microsoft Office Groove 2007 Event di FKI 2008.

Posted on June 19, 2008

Sabtu 14 juni 2008 kemarin, MUGI mendapatkan kesempatan yang sangat baik untuk melakukan unjuk gigi ke depan publik yaitu dengan berpartisipasi di dalam workshop yang diselenggarakan oleh majalah Chip.co.id dan Microsoft Indonesia. Di dalam kesempatan itu selama 2 jam saya dan oke hendradhy (wakil ketua MUGI) memberikan presentasi dan workshop tentang 2 teknologi Microsoft Office Groove 2007 dan Movie Maker versi terbaru yang sudah bundled dengan Vista. 

Pada dasarnya windows movie maker sudah bisa dipergunakan untuk membuat penggabungan dari beberapa file-file multimedia untuk bisa dikemas menjadi sebuah video yang berformat umum seperti wmv, avi dsb. Dengan fasilitas yang sudah tersedia di dalamnya kita bisa melakukan beberapa kemampuan multimedia yang cukup profesional di dalamnya. Selama kegiatan tersebut peserta cukup antusias karena banyak Souvenir yang disediakan seperti goodies dari chip dan MUGI / microsoft sendiri.

FKI2008

Sedangkan di acara Microsoft office Groove 2007 peserta yang datang semakin bertambah, sehingga acara tanya jawab dan demo semakin menarik. Yang menarik dari Office groove 2007 ini adalah kemampuan kolaborasi secara peer to peer, antara sebuah komputer yang satu dengan komputer lainnya walaupun dalam lokasi yang jauh dan tidak terhubung dalam 1 network yang sama. Di dalam workspace yang bisa dibuat dimana saja kita bisa melakukan sharring file , calendar dan beberapa tools yang menarik seperti games FKI2008-2dsb.

Sayangnya lokasi yang cukup terpisah dari lokasi pameran FKI menyebabkan  kurang banyaknya peserta yang mendatangi workshop ini. Mudah-mudahan di acara berikutnya persiapannya bisa semakin matang. Sampai jumpa di kegiatan MUGI berikut-nya.

» Filed Under MUGI | Leave a Comment

Mugi (Microsoft User Group Indonesia)

Posted on May 4, 2008

Sebenarnya awal masuk-nya saya ke MUGI ini adalah perkenalan-perkenalan sesama trainer Microsoft. Entah itu di tempat kerja saya yang lama (MII) atau sebelum-sebelumnya. Entah kenapa saya tertarik dengan MUGI mungkin karena persamaan kepentingan untuk bermain di teknologi Microsoft. Di awal-nya saya kurang banyak berkiprah banyak di percaturan ‘politik’ mugi hingga di ajak oleh rekan-rekan yang lain untuk menjadi pengurus, walaupun secara pasif :). Hingga akhirnya terjadi beberapa peristiwa yang membuat gua BT sama MUGI, karena keseringan berantem-nya. Hingga puncak-nya saat terjadi keributan sekitar 2 minggu yang lalu pada saat saya sedang di Newmont. Singkat cerita akhirnya gua angkat bicara dan selanjut-nya hingga terjadi pemilihan ketua MUGI Nasional secara dadakan.

Oleh karena sudah terpilih dan mau gak mau harus diteruskan dengan rasa tanggung jawab dalam mengemban amanah, maka saya beranikan diri mengemban tanggung jawab ini. Untung-nya rekan-rekan semua banyak memberikan dorongan dan keyakinan bahwa tugas 3 tahun ini dapat terselesaikan dengan baik.

Dalam kesempatan ini saya akan memberikan beberapa program kegiatan yang berkaitan dengan penyelenggaraan kepengurusan ini. Ditemani oleh Wakil Ketua Kang Oke (Mugi priangan) dan juga Rahmat Zikri (Sekretaris) kedepannya saya akan memberikan 2 bagian program kerja yaitu Short Term dan Long Term.

  1. Short Term (Jangka Pendek)
    • Membina Hubungan kerjasama yang erat kembali antara Microsoft dan MUGI, dengan semangat membuka lembaran baru . Sudah saatnya kita mementingkan kepentingan bersama dalam memajukan kembali MUGI di semua sektor (regional, kampus maupun Nasional)
    • Merangkul kembali semua pihak-pihak yang masih mempunyai jiwa MUGI untuk bersama-sama mencari cara mengembangkan organisasi ini secara lebih dewasa.
    • Secepatnya mengembangkan website MUGI dengan menggunakan portal dotnetnuke portal yang sedang dikembangkan oleh Riki (mugi jatabek)
    • Mencari peluang-peluang kegiatan yang bisa diselenggarakan secara independen maupun melibatkan Microsoft.
    • Pembenahan anggota organisasi agar jelas siapa yang anggota MUGI sebagai database member organisasi ini.
  2. Long Term (Jangka Panjang)
    • Membuat Agenda Kerja mulai dari semua MUGI regional maupun Nasional selama 1 tahun kedepan.
    • Melakukan penetrasi yang lebih dalam ke internal Microsoft untuk melihat semua kemungkinan pelaksanaan kerjasama / kegiatan antara MUGI dengan Microsoft.
    • Mengembalikan Citra MUGI agar semakin berkembang dan semakin luas jaringannya di seluruh Indonesia.
    • Merubah kultur / budaya kerja di seluruh MUGI untuk lebih proaktif di komunitas atau level nasional. Tidak lagi menunggu Bola tetapi mencari bola untuk pengembangan organisasi
    • Perencanaan dan Pelaksanaan Tidak ada artinya jika tidak ada pengawasan. Oleh karena itu pengawasan / monitoring pekerjaan di setiap jenjang kepengurusan mugi akan mulai diterapkan dan menjadi sebuah tolak ukur keberhasilan sebuah kepengurusan termasuk MUGI Nasional.

Demikian beberapa rencana kerja kepengurusan yang baru secara garis besar dan masih jauh dari sempurna. I need your comment’s and opinion.

Tangerang, mei 2008.

» Filed Under MUGI | 12 Comments

Ekspor user dari Access Ke SQL 2005

Posted on May 2, 2008

Microsoft Access mempunyai sebuah input mask yang sudah system defined namanya password dimana input mask ini bisa di isi menjadi sebuah nilai yang dapat dipergunakan untuk menyimpan data secara tersembunyi, seolah-olah di enkripsi. Sehingga dengan feature ini bisa dibuat sebuah tabel berisi data username dan password dari sebuah organisasi dengan tujuan untuk menyimpan siapa user yang bisa di authentikasi dengan mencari data yang berada dalam tabel tersebut serta melihat level of authorization-nya.

pic_1.JPG

Sehingga dengan menggunakan trik ini pada saat dilihat seperti tampilan berikut :

pic_2.JPG

Di SQL Server fasilitas ini tidak tersedia, akan tetapi bukan ini menjadi titik lemah di SQL Server terutama versi 2005. Di SQL Server mengenal konsep SQL Login Authentication yang berarti dengan menggunakan fasilitas ini semua obyek di SQL bisa di kontrol hak akses-nya melalui beberapa perintah DCL (data control languange). Nah bagaimana cara membuat transfer login di acess ke SQL 2005, sebenarnya ada cara yang manual yaitu dengan menggunakan management tools SQL 2005 yaitu :

  1. Arahkan  ke object explorer pane sebelah kiri layar seperti tampilan berikut :

          pic_3.JPG

2.    Klik kanan dari logins — New Login Hingga muncul : 
        pic_4.JPG
        3.  Isi login name dan pilih type authentication SQL Server Authentication.

        4.  Isi password dan konfirmasi-nya, biarkan semua setting default yang bekerja.

Dan ini dilakukan berulang kali sebanyak user yang ada, setiap user nanti-nya harus melakukan perubahan password ketika pertama kali login.

Akan tetapi ini tidak akan efektif kalo kita mengejar hampir ratusan user yang sudah ada data-nya dalam sebuah tabel access. Jadi kita menggunakan script T-SQL utk melakukan proses perubahannya secara otomatis.

Berikut Script-nya :

EXEC sp_addlinkedserver @server = ‘SourceDB’,
@provider
= ‘Microsoft.Jet.OLEDB.4.0′,
@srvproduct
= ‘OLE DB Provider for Jet’,
@datasrc = ‘D:\doc\test.mdb’

GO

Declare @uservar varchar(50),@pwd varchar(50)
declare cr_tbluser cursor  for

Select userName,password from SourceDBtbl_user

OPEN cr_tbluser

FETCH NEXT FROM cr_tbluser INTO @uservar, @pwd
WHILE @@FETCH_STATUS = 0
BEGIN
create login @uservar with password=‘Password01′ must_change,sid=newid(), check_expiration = on,check_policy = on;

FETCH NEXT FROM cr_tbluser INTO @uservar, @pwd
END
 

CLOSE cr_tbluser
DEALLOCATE cr_tbluser
 

» Filed Under Database | 2 Comments

Tutorial Penerapan Slowly Changing Dimension (Part 2)

Posted on February 11, 2008

Di Bagian pertama tulisan ini pada artikel sebelumnya, saya sudah memberikan tutorial kenapa perlu adanya Slowly Changing Dimension (SCD) dan sebuah sampel kegiatan kenapa perlu adanya SCD. Sekarang tahapan berikut-nya adalah bagaimana mewujudkan SCD dalam bentuk yang sebenarnya ketika proses ETL (Ektrak Transform and Loading) dengan menggunakan teknologi SQL 2005. Sebelumnya kita lanjutkan lakukan perintah SQL berikut untuk melengkapi proses transaksi sales order untuk Sales ber nomer SalesOrderID = 280 yang telah berubah menjadi territory 10.  Jalankan script ini di dalam SQL Managemet Studio.

Tahapan berikut-nya adalah Membuat sebuah Package di dalam Sql Server Integration Services(SSIS). Package awal-nya menggunakan sebuah package yang sudah jadi LoadDimEmployee.dtsx. Package yang sudah jadi tampilan-nya seperti ini

Control Flow

Data Flow Layout

Selanjut-nya adalah kita ingin membuat sebuah tambahan proses Slowly Changing Dimension yang akan dimasukkan ke dalam proses yang ada di dalam Data Flow Layout. Ikuti beberapa step ini :

  1. Buka Data Flow, kemudian pilih dari toolbox di bagian data flow transformations sebuah tools yaitu Slowly Changing Dimension (SCD).
  2. Klik and Drag ke dalam Layout Pane. Kemudian dari sebuah proses bernama Lookup sales territory tarik panah yang berwarna hijau ke arah kotak SCD yang barusan kita masukkan.
    SCD-1
  3. Kemudian klik kanan dari SCD tools tadi , setelah itu klik edit. Tunggu sebentar hingga muncul Sebuah wizard Slowly Changing Dimension, kemudian klik next.
  4. Dari Connection manager, pilih koneksi yang mengarahkan ke Database AdventureWorksDW, di dalam package sudah diarahkan ke chicago.adventureWorksDW yang sebenarnya mengarahkan ke server Localhost. Setelah itu klik OK.
  5. Dari Bagian Select a Dimension Table and Keys, pilih table or view = dbo.DimEmployee. Kemudian dari bagian key ubah Key Type menjadi business Key Sebuah kolom ParentEmployeeNationalIDAlternateKey , lebih jelas-nya lihat di gambar bawah ini. Kemudian Klik Next

scd2

    6.  Kemudian dari tampilan berikut-nya arahkan 2 dimension kolom yang akan dipantau perubahannya. Yaitu Lastname sebagai Changing Attribute (SCD type 1) dan SalesTerritoryKey sebagai Historical Attribute (SCD type 2). Berikut-nya klik NEXT.

   7.  Di tampilan berikut-nya, Klik Next

   8. Di Dalam tampilan berikut-nya rubah tampilannya seperti ini :
scd-3

setelah itu klik next.

   9. Di tampilan berikut-nya clear Enable Inferred Member Support
 
10.  Klik Next kemudian Finish.
 
11.  Tunggu beberapa saat kemudian muncul di bagian data flow sebuah tampilan sebagai berikut :

scd4

  12.  save package kemudian execute package, tunggu beberapa saat hingga muncul tampilan seperti ini :
scd-5

13. Proses Selesai.

Sekian bagian ke 2 dari tutorial ini, selanjutnya kita akan melanjutkan pada proses upload fact table-nya dan bagaimana hasil cube setelah SCD dilakukan.

Please feel free your comment.

regards,

» Filed Under Database | Leave a Comment

Tutorial Penerapan Slowly Changing Dimension di SQL 2005 (Part 1)

Posted on February 6, 2008

Menyambung tulisan sebelumnya tentang penggunaan Slowly Changing Dimension (SCD), saat ini saya akan memberikan sedikit tutorial tentang penerapan SCD di SQL 2005. Dalam hal ini saya akan menggunakan Database AdventureWorks dan AdventureWorksDW yang terdapat dalam sample-nya SQL 2005. Seperti kita ketahui 2 database tadi menunjukan 2 proses dalam tahapan pengembangan BI Solution, yaitu bermula dari OLTP –> Data Warehouse (staging), Star Schema sebelum menjadi sebuah cube.

Sebelumnya kita lihat kondisi tabel dan struktur data di AdventureWorks :

oltp

Fokus kita adalah sebuah tabel SalesPerson, di dalam tabel ini terdapat data Employee karyawan yang berfungsi sebagai sales di organisasi adventureworks ini. Selain itu ada data salesterritory sebagai reference tabel untuk SalesPerson yang digunakan untuk meng-identifikasi area teritory sales yang ada. Akan tetapi seiring perubahan waktu, tentunya seorang sales person akan mempunyai teritory yang berbeda seiring dengan perkembangan organisasi. Secara fisik pada saat terjadi perubahan territory sales akan menggunakan data yang terkini sehingga semua penjualan seorang sales pada waktu dia menjadi bagian dari territory sebelum-nya akan hilang, digantikan dengan penjualan seorang sales di teritory yang baru dengan data menggunakan teritori yang lama. Kalau sebuah teritori tadi menjadi bagian performance management-nya seorang branch manager, tentunya si branch manager ini akan kehilangan revenue / GP di mata management. Oleh karena itu diperlukan sebuah pendekatan khusus yang di sebut sebagai Slowly Changing Dimension (lihat blog saya sebelumnya).
Sekarang kita buat sebuah simulasi untuk melakukan sebuah proses perubahan data OLTP-nya adventureworks.

1. Execute stored Procedure dari SSMS : uspInsertSalesPerson_new (adventureWorks database), kalau belum ada silakan ambil disini script-nya. ingat jalankan script ini di AdventureWorks DB.

2.  Setelah proses pembuatan stored procedure selesai : jalankan script ini utk menambah record baru ke dalam Sales.SalesPerson tabel. :

declare @msg varchar(100)
EXECUTE [AdventureWorks].[Sales].[uspInsertSalesPerson_new]
‘123456778′
,’mr.’
,’Sony’
,’S’
,’Setiawan’
,’Sales Representative’
,’M’
,’M’
,’Pasific: Australia’
,@msg output

Hasil dari eksekusi ini akan disimpan di dalam beberapa tabel sesuai dengan diagram relationship di atas.
Langkah berikut-nya adalah melakukan update ke salah satu field yang ada di dalam sales person, misal-nya terjadi perubahan dalam informasi sales territory-nya. Sedangkan update yang satu lagi adalah update terhadap kolom lastname.

3. Untuk melakukan update silakan ambil disini sebuah file utk pembuatan stored procedure yang melakukan update terhadap data salesperson. Eksekusi di database AdventureWorks. dan kemudian eksekusi data update-nya seperti ini :

EXECUTE [AdventureWorks].[Sales].[uspUpdateSalesPerson_new]
280
,10
,’Ms.’
,’Shannon’
,’P.’
,’Elliott’

Sebagai informasi nilai yang berubah hanya nilai sales teritory ID dari 1 menjadi 10. Berarti mulai dari sekarang nilai sales teritory id utk ’shannon elliot’ menjadi 10. Kemudian eksekusi update perubahan lastName :



EXECUTE [AdventureWorks].[Sales].[uspUpdateSalesPerson_new]
277
,3
,’Ms.’
,’Linda’
,’R.’
,’Ecoffey’

Selesai Part 1:

» Filed Under Database | 2 Comments

Penggunaan Slowly Changing Dimension

Posted on February 2, 2008

Data-data history merupakan sebuah asset yang sangat berharga dalam sebuah organisasi. Akan tetapi tidak semua data history itu berguna. Sebagai ilustrasi ketika terjadi perpindahan pegawai atau sales dari organisasi kerja antar departemen yang berbeda atau antar cabang, tentunya kita tidak ingin semua data transaksi-nya hilang begitu saja. Kita tentunya tahu dalam pembuatan sebuah star schema (data warehouse) sebuah dimension dipakai untuk merepresentasikan dari sudut pandang mana sebuah data akan diukur (measures). Di dalam konsep tradisional pembentukan sebuah dimension, semua data-data reference dari sebuah transaksi hanya akan memiliki satu record saja.

Lihat diagram dibawah ini tentang penggambaran sebuah dimensi employee :

scd-1

Kita lihat dua kotak sebelah kanan merupakan repsentasi sebuah record no 295, di kotak bagian before adalah kondisi record sebelum di rubah dan kotak yang sebelah kanan hasil perubahan yang terjadi di dalam record tersebut. Jadi ketika terjadi perubahan dalam record di tabel dimEmployee, perubahan data yang lama dengan yang baru akan dilakukan proses data yang lama akan di-timpa (replace) dengan data yang baru. Efeknya adalah data-data transaksi yang lama dan berkaitan dengan dimEmployee tersebut akan berubah mengikuti perubahan tadi. Jika di organisasi tersebut ingin melihat data-data transaksi lama sebelum data dimEmployee berubah tidak akan bisa dilihat, karena data tersebut sudah digantikan dengan data reference yang baru.

scd-2

Sedangkan gambar di atas merupakan penggambaran SCD type-2. Coba perhatikan data sebelumnya menggunakan nilai 9 di dalam field SalesTeritoryKey dan di kolom end date data-nya masih NULL. Setelah terjadi proses perubahan data contoh-nya pindah sales teritory di dalam record lama akan terjadi proses expiry yaitu menambah data di dalam kolom end date dengan tanggal saat terjadi perubahan. Dan akan dibuat sebuah record baru yang menampung perubahan data-nya dan data yang lama. Lihat di record yang baru nilai employeeKey berubah sesuai nilai identity-nya (auto number). sedangkan info yang lain masih sama kecuali field SalesTeritoryKey yang berubah menjadi 10, dan start date-nya menjadi tanggal data yang baru.

Itulah penggunaan Slowly Changing Dimension, didalam artikel berikut-nya kita lihat bagaimana menggunakan SCD dengan SQL Server 2005.

» Filed Under Database | Leave a Comment

Penerapan Knowledge management di Organisasi kerja pemerintahan

Posted on January 12, 2008

Organisasi kerja pemerintahan disini termasuk Departemen, kementrian dan juga pemerintahan daerah. Pertama pada saat mendengar organisasi pemerintahan mungkin timbul pertanyaan apakah memungkinkan penerapan knowledge management di lingkungan kerja yang sarat dengan isu budaya kerja santai dan mempunyai kecenderungan ABS (asal bapak senang). Tentunya jawaban-nya beragam dan sangat tergantung pada unsur leadership di organisasi tersebut. Mengapa saya bilang unsur leadership mempunyai peranan yg sangat penting ? Karena ciri khas di beberapa departement pemerintahan umumnya selalu menggunakan top down approach. Pendekatan ini merupakan salah satu peninggalan konsep sentralisasi dimana ide dan kreasi dari bawah masih takut untuk ditunjukan ke publik. Kembali ke topik utama tentang penerapan knowledge management di organisasi, saya melihat dari hasil pengalaman secara umum di lapangan tahapan penerapan bisa dibagi menjadi 3 tahap antara lain adalah sbb:

1. Awareness
Di dalam tahap ini pemahaman terhadap knowledge management harus dibuat dengan cara sosialisasi kepada semua level tapi tidak melebar hingga lingkup yang terlalu luas. Dalam tahapan ini perlunya kesadaran top level management terhadap penting-nya knowledge management.
2. Assessment
Dalam tahap ini kita harus bisa melakukan sebuah analisa terhadap kondisi yang ada saat ini dan membuat sebuah pendekatan praktis mana yang bisa dilakukan perbaikan dengan mempertimbangkan keuntungan dan kerugian dari setiap pendekatan tadi.

3. Design system
Setelah tahapan assessment selesai dan memberikan beberapa alternatif solusi. Di dalam tahapan design system akan ditentukan solusi mana yang akan diterapkan dalam penyelesaian project KM. Semua teknologi dan solusi yang ada di telaah dan disesuaikan dengan kondisi yang ada, termasuk budget pelaksanaan pekerjaan serta kualitas SDM.

4. Implementation
Semua desain system yang sudah dibuat dilaksanakan dan dimonitor pelaksanaannya. Di dalam tahapan ini semua kejadian yang tidak terbayangkan pada saat desain system akan muncul, sehingga disinalah dibutuhkan pendekatan seorang project manager yang dapat menentukan tindak lanjut proyek ini. Umumnya seorang PM harus dapat menentukan kapan sesuatu yang di luar desain system harus di akomodir atau tidak. Kultur di sebuah lembaga pemerintahan yang umumnya terjadi adalah ketidakmampuan kita melakukan capture terhadap ownership solusi KM ini. Di awal seringkali pada saat kita melakukan assessment system, kita mendapati bahwa orang yang kita assess ternyata orang kurang tepat, sehingga pada saat selesai proyek ternyata orang yang melakukan pengetesan melihat sesuatu yang tidak sesuai dengan keinginan mereka, sehingga harus dirubah desain system-nya. Saran saya dalam hal ini adalah dokumentasi-kan semua kegiatan yang berkaitan dengan proyek ini dan minta pejabat / staf terkait yang berani bertanggung jawab dan simpan sebagai bagian dari dokumentasi proyek. Ini digunakan untuk menjaga kemungkinan-kemungkinan yang dapat saja terjadi pada saat tahapan implementasi proyek ini.

5. Socialization.
Setelah semua-nya selesai terkadang tugas kita belum selesai saja sampai disitu, diperlukan sebuah proses tambahan yang biasa disebut sebagai sosialisasi ke pengguna, disinipun harus dihindari beberapa permintaan di luar dari desain system karena sekali kita ikuti 1 permintaan mereka maka akan terjadi ‘NEVER ENDING PROJECT’ yang efeknya nanti akan mengakibatkan semakin tertundanya penerapan akhir dari proyek KM ini.

» Filed Under Knowledge Management | 3 Comments

Membuat Desain Datawarehouse dengan MS SQL 2005

Posted on December 23, 2007

Beberapa praktisi di bidang teknologi Business Intelligence mengutarakan sebuah fakta bahwa hampir 80% kesalahan fatal dari pengembangan sebuah proyek BI / datawarehouse adalah kesalahan assessment kebutuhan dan desain dari star schema. Star schema sendiri merupakan sebuah desain standard di teori datawarehouse untuk membuat sebuah database siap dijadikan menjadi Cube atau bentuk MultiDimensional Database. Beberapa kaidah yang perlu diperhatikan dalam membuat desain datawarehouse adalah sebagai berikut :

  1. Apakah di dalam 1 database star schema akan dipakai oleh lebih dari 1 buah fokus bisnis proses. Fokus bisnis proses itu merupakan sebuah proses pekerjaan yang akan kita ukur pekerjaannya contohnya adalah sales, purchasing, human resource, production dan masih banyak lainnya. Jika nantinya di dalam sebuah star schema design akan menggunakan lebih dari 1 fokus bisnis proses berarti kita harus mempersiapkan tabel - tabel dimension yang nanti-nya bisa digunakan untuk semua proses fokus bisnis.
  2. Kebutuhan minimal desain 1 buah database star schema adalah terdiri dari minimal 1 buah fact table , 1 measure dan 1 buah dimension table.
  3. Kebutuhan sebuah tabel dimension terhadap surrogate key harus disesuaikan dengan proses bisnis yang mengacu kepada dimension table tersebut.
  4. Keberadaan data yang terdapat didalam dimension table dan fact table harus dijaga dengan menggunakan referential integrity antara dimension tabel dan fact table-nya.

secara umum gambaran dari diagram star schema seperti ini :

Tabel sales yang berada di tengah-tengah itu yang akan menjadi fact table-nya. Kemudian tabel store,time,product,promotion dan customer mereka itulah yang disebut sebagai tabel-tabel dimensi.

Di dalam tulisan ini saya menyajikan contoh pembuatan desain database star schema dengan menggunakan data sumber OLTP-nya menggunakan database AdventureWorks database. Di dalam contoh ini saya menggunakan proses bisnis purchasing yang menggunakan sumber data fact table-nya menggunakan 2 buah tabel yaitu : purchasing.purchasingOrderHeader dan purchasing.purchasingOrderDetail. Hasil desain yang saya buat secara umum mempunyai deskripsi susunan dimension dan fact table dan measure sebagai berikut :

Dimension Table :
dimTime
Year
|- Quarter
|- Month

dimProduct
Category
|- SubCategory
|- Product

dimEmployee (Parent Child Dimension table)
ManagerID
|- EmployeeFullName

dimShipMethod
ShipMethodNamedimVendor
VendorCountry
|- VendorProvince
|- VendorCity
|- VendorName

Fact Table :
Measures :
OrderQuantity
LineTotal
ReceivedQuantity

Berikut desain starschema fisik-nya :

Script database ini bisa di ambil di http://miimlc.metrodata.co.id/forum/files/folders/microsoft_training/entry54.aspx

Sekian dulu tulisan saya tentang pembuatan desain datawarehouse POAdventureWorks, tulisan saya berikut-nya tentang proses ETL (Extraction Transform and Loading) dari adventureworks ke POAdventureworks dengan menggunakan SSIS 2005.

Feel free for your comment.

» Filed Under Database | 2 Comments

Membuat Audit delete record log dengan trigger MS SQL 2005

Posted on December 23, 2007

Tulisan ini sebenarnya merupakan pemenuhan janji saya kepada salah satu peserta training yang ingin mengetahui tentang konsep Auditing Record Log di sebuah database MS SQL Server 2005 (any edition). Saya mohon maaf kepada Pak Indra yang sudah menanti cukup lama untuk tulisan ini Smile.

Kita mulai dari cara yang sederhana yaitu dengan membuat sebuah database / menggunakan sebuah database yang sudah ada. Beberapa prasyarat awal untuk mengetahui lebih detail konsep ini bisa dimulai pemahaman tentang Trigger. Kenaapa menggunakan trigger ? Sebagai sebuah object database yang sebenarnya ‘berdiri sendiri’, trigger mempunyai kemampuan utk meng-antisipasi sebuah aksi yang dilakukan ke database / table dengan merespon balik berupa reaksi terhadap table itu sendiri (tempat trigger berada) / kepada object (table,view dll) yang juga terdapat di dalam database itu. Fungsi trigger sebenarnya mirip Check constraint tetapi  trigger mempunya fungsionalitas yang lebih luas dibandingkan dengan Check Constraint.

Mari kita mulai pembahasan topik ini dengan membuat sebuah skenario berikut : Sebuah aplikasi berbasis windows based client dan database MS SQL 2005 sebagai backend-nya sering mendapatkan sebuah kasus dimana database-nya / tabel / record-nya tiba-tiba data-nya menghilang, sebagai seorang DBA tentunya kita harus mempunyai cara untuk mengetahui siapa, kapan, dan lewat mana data tersebut ‘terhapus’ entah itu sengaja atau tidak sengaja. Beberapa prasyarat untuk membuatnya adalah sebagai berikut :

  1. Tentukan terlebih dahulu mana tabel yang akan di audit, karena semakin banyak trigger yang harus di aktifkan di sebuah database dapat menurunkan performance dari database tersebut.
  2. Buat database dan table kosong yang baru di SQL 2005 dengan menggunakan SQL Management Studio nama-nya terserah anda : “testingAudit” dengan menggunakan konfigurasi standard :

    create database testingAudit
    go
    create table testDelete
    (
    id_record varchar(5),
    Deskripsi varchar(20)
    )
    go

    ‘insert data dummy ke table testDelete, jalankan script :

    insert into testDelete values (’ABC’,'testing 123′)
    insert into testDelete values (’BCD’,'testing 124′)
    insert into testDelete values (’CDE’,'testing 125′)
    insert into testDelete values (’EFG’,'testing 126′)
    insert into testDelete values (’FGH’,'testing 126′)
    insert into testDelete values (’GHI’,'testing 127′)
    insert into testDelete values (’HIJ’,'testing 128′)
    insert into testDelete values (’IJK’,'testing 129′)
    insert into testDelete values (’JKL’,'testing 130′)
    insert into testDelete values (’KLM’,'testing 131′)
    insert into testDelete values (’LMN’,'testing 132′)
    insert into testDelete values (’MNO’,'testing 133′)

  3. Setelah kita tentukan tabel mana yang akan di audit yaitu testdelete table, buatlah sebuah tabel yang dimanfaatkan sebagai audit log table yang di dalamnya terdapat beberapa informasi seperti : deleted_date_hour_minute,who_deleted,id_record_deleted,application. Berikut contoh script untuk membuat tabel-nya :
    use testingAudit
    go
    create table log_record
    (
    dateDeleted datetime,
    personWho varchar(30),
    Id_record varchar(10)
    )
  4. Setelah table log dibuat, tahap berikut-nya adalah membuat trigger on delete di dalam table testDelete
    Setiap perintah transaction (insert,update,delete) statement di table MS SQL Server pasti selalu muncul beberapa table sementara yang hanya muncul disaat eksekusi trigger. Table-table itu diantaranya adalah sebagai berikut :
    -   inserted (muncul pada saat terjadi proses transaksi perintah insert terhadap sebuah tabel)
    -   deleted (muncul pada saat terjadi proses transaksi perintah delete terhadap sebuah tabel)
    -   Sedangkan untuk transaksi Update , proses yang terjadi adalah deleted yang pertama kali di kerjakan baru setelah itu Inserted.

    Gambaran script untuk pembuatan trigger-nya adalah sebagai berikut :
    create trigger tr_test on testdelete
    for delete
    as
    declare @date1 datetime,@person varchar(30) , @id varchar(10)
    set @date1 = getdate()
    set @person = suser_sname()
    select @id = id_record from deleted
    insert into log_record values (@date1,@person,@id)

  5. Pastikan trigger tr_test sudah terdapat dalam tabel testDelete, dengan menggunaan SSMS (SQL Server Management Studio).
  6. Coba jalankan perintah delete terhadap 1 record di tabel testDelete kemudian cek apakah log_record table telah terisi siapa, kapan dan record mana yang terhapus.
  7. Tolong dipastikan juga bahwa user yang authorized delete record di testDelete bisa melakukan perintah insert di table log_record.
  8. Selamat mencoba.

Feel free your comment,

Sony

» Filed Under Database | 3 Comments

keep looking »

  • About

    I'm not a geek I' just a person who like to share knowledge that I have. Born in Bandung 36 years ago. Right now I'm a free man not belong to any company .