Data warehouse ( Resume Pertemuan 6 )

NIM : 10410100104

v Logical & Physical Data Design

Pemodelan logis dimulai dengan mengumpulkan kebutuhan bisnis dan mengkonversi kebutuhan tersebut ke dalam model. Model logis berkisar pada kebutuhan bisnis, bukan database, meskipun kebutuhan bisnis digunakan untuk menetapkan kebutuhan database. Pemodelan logis melibatkan pengumpulan informasi tentang proses bisnis, badan usaha (kategori data), dan unit organisasi. Setelah informasi ini dikumpulkan, diagram dan laporan yang dihasilkan termasuk diagram hubungan entitas, diagram proses bisnis, dan akhirnya diagram alur proses. 

Diagram yang dihasilkan harus menunjukkan proses dan data yang ada, serta hubungan antara proses bisnis dan data. Pemodelan logis harus akurat dalam membuat representasi visual dari kegiatan dan data yang relevan dengan bisnis tertentu.

Ø  Perancangan Database

™ Langkah-langkah merancang database yang baik :

1. Pemilihan proses
2. Pemilihan sumber
3. Mengidentifikasi dimensi
4. Pemilihan fakta
5. Melengkapi tabel dimensi
6. Pemilihan durasi database
7. Menelusuri perubahan dimensi yang perlahan
8. Menentukan prioritas dan mode query

Fase selanjutnya dari perancangan database adalah membuat sebuah skema konseptual dan skema eksternal pada model data dari DBMS yang terpilih. Pada fase ini, skema konseptual ditransformasikan dari model data tingkat tinggi yang digunakan.

Ø  Pemetaannya dapat diproses dalam 2 tingkat :

1. Pemetaan system-independent :

   Pemetaan ke dalam model data DBMS dengan tidak mempertimbangkan karakteristik atau hal-hal yang khusus yang berlaku pada implementasi DBMS dari model data tsb.

2. Penyesuaian skema ke DBMS yang spesifik :

   Mengatur skema yang dihasilkan pada langkah 1 untuk disesuaikan pada implementasi yang khusus di masa yang akan datang dari suatu model data yang digunakan pada DBMS yang dipilih.

Hasil dari fase ini memakai perintah-perintah DDL dalam bahasa DBMS yang dipilih yang menentukan tingkat skema konseptual dan eksternal dari sistem database. Tetapi dalam beberapa hal, perintah-perintah DDL memasukkan parameter-parameter rancangan fisik sehingga DDL yang lengkap harus menunggu sampai fase perancangan database secara fisik telah lengkap.

Fase ini dapat dimulai setelah pemilihan sebuah implementasi model data sambil menunggu DBMS yang spesifik yang akan dipilih. Contoh: jika memutuskan untuk menggunakan beberapa relational DBMS tetapi belum memutuskan suatu relasi yang utama. Rancangan dari skema eksternal untuk aplikasi-aplikasi yang spesifik seringkali sudah selesai selama proses ini.

Ø  Tujuan perancangan database :

•  untuk memenuhi informasi yang berisikan kebutuhan-kebutuhan user secara khusus dan aplikasi-aplikasinya.

•    memudahkan pengertian struktur informasi

• mendukung kebutuhan-kebutuhan pemrosesan dan beberapa obyek penampilan (response time, processing time, dan storage space)

Ø  Model Datawarehouse (OLTP)

™ Model Dimensional : menggunakan konsep model hubungan antar entity (ER) dengan beberapa batasan yang penting. Setiap model dimensi terdiri dari sebuah tabel dengan sebuah komposit primary key,  disebut dengan table fakta, dan satu set table yang lebih kecil disebut table dimensi.

Gambar 1.0 Model Data OLTP

Gambar 1.1 Model Star Skema

Gambar 1.2 Starflake Skema

Gambar 1.3 Snowflake Skema

Ø  Agregasi

Merupakan fenomena terjadinya relasi yang mensyaratkan adanya relasi yang lain.

™ Contoh,

    Pada tabel himpunan entitas mahasiswa dan mata kuliah, terdapat beberapa mata kuliah yang mensyaratkan ada praktikum dalam matakuliah tersebut maka, diagram E-R nya adalah sebagai berikut :

Gambar 1.4 ER

Ø Model Fisik

Pemodelan fisik melibatkan desain yang sebenarnya konversi dari database logis sesuai dengan persyaratan yang ditetapkan dari pemodelan data logis. Tahap – tahap desain Fisik yakni :

Gambar 1.5 Tahapan desain fisik

Ø  Penyimpanan Fisik

Gambar 1.6 Penyimpanan fisik

Ø  Tujuan Physical Design

1.      Meningkatkan Kinerja, kinerja dalam suatu lingkungan OLTP berbeda dengan dalam lingkungan Data Warehouse dalam hal online response times.

2.      Memastikan Skalabilitas, merupakan tujuan utama. Penggunaan Data Warehouse bereskalasi dari waktu ke waktu dengan peningkatan yang lebih tajam pada periode awal. Penggunaan Data Warehouse meningkat dalam dua hal, yakni Jumlah pengguna yang meningkat secara cepat dan kompleksitas kueri.

3.      Mengatur Media Penyimpanan, agar dapat meningkatkan kinerja dengan penyimpanan tabel terkait dalam file yang sama.

4.      Memberikan kemudahan Administrasi

5.      Desain untuk Fleksibilitas,  Jika terjadi perubahan terhadap model data,mudah untuk melakukan perubahan terhadap model fisiknya.

Perbedaan Desain Logis dan Fisik :

Gambar 1.7 Perbedaan desain Logik dan fisik

Gambar 1.8 Perbedaan bentuk logikal model dan physical model

™ NB : Materi ini saya resume berdasarkan materi – materi yang diberikan oleh dosen saya untuk bahan presentasi J . Untuk lebih lengkapnya, silahkan anda download file PPT presentasi disini :

         DOWNLOAD FILE PPT

Star Skema dan Snowflake skema

NIM : 10410100104

SKEMA DATABASE

v  STAR SKEMA ( order )

 Nortwind Database Model

Dimensional Format

Relational Format

Star skema

Snowflake skema

DATA WAREHOUSE - TUGAS ( PERTEMUAN 4 )

NIM : 10410100104

Arsitektur dan Infrastruktur yang dipakai PT. ASCO AUTOMOTIVE

v  Infrastruktur :

Terdapat 2 Infrastruktur yakni infrastruktur operasional dan infrastruktur fisik.

Infrastruktur operasional :

-          Orang-Orang

-          Prosedur

-          Pelatihan

-          Manajemen perangkat Lunak

Infrastruktur Fisik :

-          Hardware

-          Operating Sistem

-          DBMS

-          Network Software

v  Arsitektur Analisis Sistem Modul Pembelian

v  Proses Pembelian Alokasi Standart dan Khusus

·         Alokasi standar. Alokasi standard ini dapat berlaku untuk tipe pembayaran COD (cash on delivery) atau TOP (terms of Payment). Struktur harga perolehan untuk kategori alokasi standard adalah: Harga/unit (sudah termasuk Ppn 10% dan Ppn BM), besarnya Ppn BM tergantung pada jenis atau tipe kendaraan. Kelompok biaya ini dicatatkan dalam satu giro tertentu. Pph 6% dicatatkan pada giro terpisah. Deposit, besarnya tergantung pada tipe atau jenis kendaraan

·         Alokasi khusus. Alokasi khusus ini dilakukan dengan melakukan negosiasi untuk meminta kepastian unit, harga dan jadwal pengiriman. Tipe pembayaran untuk alokasi khusus ini adalah COD dan TOP. Harga/unit (sudah termasuk Ppn 10% dan Ppn BM), besarnya Ppn BM tergantung pada jenis atau tipe kendaraan. Kelompok biaya ini dicatatkan dalam satu giro tertentu. Pph 6% dicatatkan pada giro terpisah Deposit, besarnya tergantung pada tie atau jenis kendaraan. Administration Fee, besarnya berupa persentase dikalikan dengan harga/unit. Administration fee ini dibayarkan secara periodik. Besarnya persen yang harus dibayarkan tergantung dari negosiasi.

v  Skenario Pembayaran dengan Leasing

v  Skenario Pembayaran dengan Avalis

v  Aliran Proses Distribusi Kendaraan dari pusat wilayah dan ke anak wilayah (cabang)

·         Modul ini adalah kelanjutan dari proses pembelian. Terdapat 2 jenis proses :

-          Proses pengiriman barang oleh KTB

Setelah setoran pembayaran diterima oleh KTB, maka dilanjutkan dengan proses pengiriman barang oleh KTB. Pengiriman kendaraan langsung menuju pada cabang-cabang yang membutuhkan, sesuai alokasi yang diatur oleh pusat. Namun segala dokumen yang bersangkutan dengan kendaraan tetap diantarkan ke pusat.

-          Pelaporan terjadinya penjualan oleh cabang

Jika terjadi pembelian kendaraan oleh customer, maka cabang harus melaporkan ke pusat, karena customer tersebut akan menerima kupon free service, sekaligus melaporkan kondisi stock terakhir.

v  Modul Penjualan

·         Proses utamanya adalah :

1. Customer melakukan permintaan atas tipe produk tertentu dengan warna dan aksesoris tertentu.

2. Perusahaan memeriksa stock.

3. Jika stock tersedia di saat customer melakukan permintaan, maka permintaan tersebut dapat langsung dilayani.

4. Jika tidak, maka permintaan tersebut diperlakukan sebagai indent.

5. Jika stock yang diminta telah tersedia maka ditindak lanjuti oleh perusahaan dengan pembuatan nota yang berisi kewajiban jumlah pembayaran yang harus dipenuhi oleh customer. Jika customer telah menyetujui nota tersebut, maka proses penjualan telah berakhir.

Selain melayani penjualan, divisi ini juga melayani karoseri kendaraan sesuai keinginan customer. Dalam pelayanan karoseri terdapat 2 jenis proses yang dilakukan, yaitu :

1. Order Karoseri. Menginput konfirmasi perubahan chasis dari cabang ke pusat

2. Terima dari Karoseri. Menginput data penerimaan kendaraan dari perusahaan karoseri

·         Pada Proses bisnis ini sering ditemui permasalahan sebagai berikut :

1. Mekanisme pemberian Kredit. Diharapkan dapat dirumuskan suatu konsep Decision Support System yang dapat membantu perusahaan untuk menentukan secara cerdas pemberian kredit kepada calon pembeli.

2. Mekanisme pemberian Diskon.

3. Pemanfaatan Tenaga Penjual yang optimal dengan mengembangkan konsep-konsep CRM.

4. Tidak tersedianya informasi usia stock yang dimiliki saat ini

5. Tidak tersedia laporan lengkap secara ringkas, tepat guna dan dalam waktu yang relatif singkat, untuk kebutuhan pembuatan kebijakan bagi pihak manajerial. Laporan lengkap yang diingini meliputi:

- Laporan stock

- Laporan posisi keuangan saat ini, meliputi:

- Harga Setor, yaitu harga yang dibayarkan oleh grup dealer kepada ATPM

- Harga jual yang diberikan dealer kepada customer

- Laporan piutang beserta usia piutang

v  Modul Service & Body Repair

v  Keterkaitan antar role dalam proses servis

·         Urutan proses yang terjadi :

1. Pemeriksaan data historis dari customer yang datang

2. Pencatatan keluhan

3. Analisis proses perawatan dan monitoring yang akan dilakukan oleh Service Consultant, meliputi:

a. Estimasi Sparepart yang dibutuhkan

b. Estimasi Waktu pengerjaan

c. Estimasi biaya keseluruhan

4. Pengeluaran Work Control dan pengaturan grup mekanik oleh kepala bengkel.

5. Pengaturan dan pengendalian kerja mekanik yang dilakukan oleh leader

6. Pengawasan kualitas, produktivitas dan efisiensi oleh mekanik.

7. Pemeriksaan Final kualitas kerja oleh leader

8. Work Control diterima kembali oleh Kepala Bengkel

9. PenutupanWork Order dan penerbitan faktur Service oleh Administrasi Service

10. Informasi pekerjaan dan biaya oleh Service Consultant

11. Penerimaan Pembayaran oleh Kasir

12. Satpam memandu kendaraan keluar

·         Proses yang terjadi :

1.      Proses Permintaan barang oleh customer.

2.      Stocking, yaitu proses pengadaan stock. Terdapat dua jenis Stocking :

a. Reguler Order, dilakukan per minggu

Berupa pemesanan terhadap fast moving sparepart

b. Emergency Order

Berupa pemesanan terhadap sparepart tertentu

3.      Order dilakukan kepada KTB, dengan waktu kedatangan sparepart adalah 1 hari setelah pemesanan

Kondisi aktual sistem informasi di PT. Asco Automotive dapat dibedakan menjadi dua domain subsistem, yaitu yang berkaitan dengan infrastruktur ’hardware’ sistem informasinya dan yang berkaitan dengan infrastruktur ’software’ sistem informasinya.

Infrastruktur perangkat lunak ini dapat ditinjau dari dua sisi pandang, yaitu ditinjau dari konfigurasi arsitektur engineering dan ditinjau dari infrastruktur konfigurasi modul aplikasi. Secara umum arsitektur aplikasi yang ada di PT. Asco Automotive dapat dilihat pada gambar 1.

·         Arsitektur Aplikasi PT. Asco Automotive

Setelah melakukan assesment ke PT.LBUM, maka dapat menyimpulkan beberapa hal yang berkaitan dengan kondisi umum yang merupakan sumber permasalahan bagi PT.LBUM

1. Sekarang ini, aplikasi yang digunakan oleh PT. Asco Automotive  ’seolah-olah’ terkotak-kotak untuk setiap lini proses bisnisnya dan terkotak-kotak antara pusat dan wilayah yang diakibatkan oleh :

a. Teknologi pengembangan sistem aplikasi pada masa itu (2008) sudah ‘obsolete’ dan tidak dapat mensupport proses bisnis PT. LBUM yang semakin meluas.

b. Ketika dilakukan pengembangan sistem aplikasi pada masa itu, belum diantisipasi kemungkinan inter-operasi antar divisi serta dibuat atas arsitektur aplikasi yang komprehensif dan ter-integrasi antara kantor pusat-wilayah-anak wilayah.

c. Server data base yang terpisah-pisah antara pusat dan wilayah sehingga harus dilakukan sinkronisasi data secara manual antara pusat dan wilayah. Misalnya untuk mengupdate status stok kendaraan, maka ketika terjadi penjualan di wilayah, maka pihak wilayah harus melapor ke pihak pusat dan pihak pusat harus menginput penjualan yang terjadi pada aplikasi yang ada dan status inventori akan ter-update.

2. Banyak kejadian-kejadian khusus atau perubahan-perubahan minor pada aplikasi yang tidak dapat diakomodasi oleh sistem informasi yang ada, misalnya : penambahan data yang harus dimunculkan pada suatu User interface, atau penambahan data yang harus dimunculkan dalam laporan, walaupun sebenarnya data tersebut sudah tersedia dalam data base. Saat ini, PT. LBUM tidak memiliki teknologi yang memiliki kemampuan untuk mengakomodasi situasi-situasi di atas.

Setelah dilakukan penilaian atas kondisi aktual di PT. LBUM (Mereferensi pada dokumen ”Pemetaan Proses Bisnis dan Sistem yang digunakan saat ini di PT. Asco Automotive”), maka diusulkan untuk melakukan pengembangan sistem informasi secara ’FUNDAMENTAL’, dengan tetap mengacu pada konsep proses bisnis yang ada.

Konsep solusi ’Fundamental’ ditawarkan kepada PT.LBUM ini, merupakan solusi sistem informasi Enterprise Resource Planning (ERP), yang akan dibangun ulang berdasarkan konsep aplikasi yang sudah ada dan pengembangan konsep sistem informasi berdasarkan hasil konsultasi konsep solusi yang akan dilakukan ketika aplikasi akan dikembangkan. Konsep ini menuntut adanya perubahan perilaku organisasi dalam menyikapi sistem informasi yang baru yang artinya harus mengubah budaya perusahaan secara keseluruhan. Keberhasilan implementasi sistem informasi secara fundamental ini, tidak hanya ditentukan oleh kualitas aplikasi yang telah dikembangkan, tetapi juga perlu didukung sepenuhnya oleh pihak manajemen untuk melakukan pendekatan top-down dan kerja sama user untuk mau belajar menggunakan sistem informasi yang baru.

·         Manfaat  yang bisa dipetik dari solusi ini adalah :

1.      Meningkatkan efisiensi dan efektifitas kerja, yaitu dengan hilangnya akitivitas yang tidak perlu, misal: ’double-entry’ yang dilakukan oleh admin. Hal ini, tentunya akan meminimasi multiplier efek dari ’human eror’.

2.      Meningkatkan produktivitas kerja karena aplikasi dibangun atas dasar konsep yang ’user friendly’, dilengkapi fitur-fitur yang membantu user dalam menyelesaikan tugas hariannya, kemampuan interoperasi antar subsistem dalam aplikasi dan availability yang baik.

3.      Mengurangi biaya, khususnya biaya administrasi, misalnya: yang semula harus dilakukan secara manual (dengan menggunakan piece of paper), sekarang dapat dilakukan secara otomatis.

4.      Memudahkan pengendalian atas proses bisnis yang dilakukan karena data dapat dengan mudah ditelusuri.

     ·      Usulan Arsitektur Solusi Aplikasi

·         Usulan Arsitektur Proses Bisnis

·         Secara umum modul utama dalam pengembangan aplikasi ini adalah :

Modul Administrasi dan Setting. Modul ini merupakan modul untuk menginput: (1) Data master atau data referensi global;(2) Data entitas yang terlibat dalam proses bisnis (baik sebagai obyek maupun sebagai subyek); (3) Data pengaturan aturan-aturan bisnis.

Modul Proses bisnis (transaksional). Modul ini merupakan modul yang men-support proses transaksional yang terjadi dalam suatu proses bisnis, yang meliputi: (1) Pembelian; (2) Inventory; (3) Distribusi; (4)Penjualan;(5) Divisi Mobil Bekas; (6) Divisi Sparepart; (7)Servis; (8) Customer Service; (9) Divisi Body Repair.

Modul Laporan. Modul ini adalah modul laporan transaksional, yaitu meliputi : (1) Laporan OLAP ; (2) Laporan Standar ; (3) Summary atau daftar dokumen atau daftar transaksi.

Modul Akuntansi dan Keuangan. Modul ini adalah modul laporan yang berhubungan dengan akuntansi dan keuangan, misalnya laporan status A/P dan A/R, laporan rugi laba dan laporan neraca keuangan.