indomaret2

55

Bab 3

Analisis dan Perancangan

3.1 Gambaran Umum Perusahaan

3.1.1 Sejarah PT. Indomarco Prismatama

PT Indomarco Prismatama adalah perusahaan pengelola jaringan

minimarket Indomaret. Indomaret merupakan salah satu jaringan minimarket di

Indonesia yang menyediakan kebutuhan pokok dan kebutuhan sehari-hari. Awal

terbentuknya perusahaan ini diawali dari sebuah toko Indomaret yang

menyediakan kebutuhan pokok dan kebutuhan sehari-hari yang pertama kali

dibuka pada tahun 1987 di Pontianak, Kalimantan Barat. Tokoh yang merintis

berdirinya perusahaan ini adalah Sudono Salim beserta anaknya yakni Anthony

Salim. Tokoh ayah dan anak ini juga dikenal luas sebagai pengusaha yang sukses

antara lain sebagai pemilik perusahaan Bogasari, Indofood, Indosiar, dan lain-lain.

Usaha ini mulai berkembang ketika PT Indomarco Prismatama pertama

kali membuka gerai Indomaret di Jakarta yang berlokasi di Ancol, Jakarta Utara

pada November 1988 yang kemudian disusul dengan pembukaan gerai-gerai

Indomaret di tempat-tempat lainnya. Pada tahun 1997, setelah 230 gerai Indomaret

terbukti menguntungkan, PT. Indomarco Prismatama mulai memperkenalkan

sistem kemitraan kepemilikan dan pengelolaan gerai dengan cara waralaba dan

mengembangkan bisnis gerai waralaba pertama di Indonesia. Mitra usaha waralaba

ini meliputi koperasi, badan usaha dan perorangan. Pada Mei 2003, sistem

waralaba Indomaret telah terbukti keberhasilannya dengan diperolehnya

penghargaan dari Presiden Republik Indonesia saat itu yaitu Presiden Megawati

56

Soekarno Putri sebagai Perusahaan Waralaba Nasional 2003. Saat ini Indomaret

berjumlah 3531 gerai di mana 1998 gerai adalah milik sendiri dan 1533 gerai

sisanya merupakan gerai waralaba milik masyarakat yang tersebar di berbagai

wilayah seperti Jabodetabek, Jawa Barat, Jawa Tengah, Jawa Timur, Yogyakarta,

Bali, Medan, dan Lampung. Di DKI Jakarta sendiri telah hadir sekitar 488 gerai

Indomaret yang siap memenuhi hampir semua kebutuhan sehari-hari konsumen

dengan menawarkan lebih dari 3.500 jenis produk makanan dan non-makanan

dengan harga bersaing.

Segmen pasar yang menjadi sasaran Indomaret adalah konsumen dari

semua kalangan masyarakat sehingga penempatan lokasi gerai-gerai Indomaret

dapat dengan mudah ditemukan di mana saja seperti daerah perumahan, gedung

perkantoran, dan fasilitas umum. Penempatan lokasi gerai yang strategis, yang

sesuai dengan motto Indomaret yaitu “Mudah dan Hemat”, ditujukan untuk

memudahkan Indomaret melayani sasaran demografisnya yakni keluarga.

Hubungan kerja sama yang dijalin dengan lebih dari 500 pemasok

membuat Indomaret memiliki posisi yang baik dalam menentukan produk-produk

yang akan dijualnya. Selain itu, sistem distribusi yang didukung oleh jaringan

pemasok yang handal dalam menyediakan produk terkenal dan berkualitas serta

sumber daya manusia yang kompeten menjadikan Indomaret sangat efisien dalam

mendistribusikan produknya sehingga Indomaret mampu memberikan pelayanan

yang terbaik kepada para konsumennya.

Strategi pemasaran Indomaret juga diintegrasikan dengan kegiatan-kegiatan

promosi yang dilaksanakan sehingga Indomaret dapat secara berkala menjalankan

57

berbagai program promosi seperti memberikan penawaran harga khusus, undian

berhadiah maupun hadiah langsung.

Keberadaan Indomaret ini juga diperkuat oleh beberapa anak perusahaan di

bawah bendera grup INTRACO seperti Indogrosir, BSD Plaza dan Charmant.

Keunggulan-keunggulan yang telah dimiliki oleh Indomaret tersebut tidak

menyurutkan semangat PT. Indomarco Prismatama untuk terus berusaha

mengembangkan Indomaret sebagai jaringan minimarket terbaik di Indonesia.

3.1.2 Visi, Misi, Motto, dan Budaya Perusahaan

Visi dan misi PT. Indomarco Prismatama tentunya berkaitan dengan

Indomaret yakni sebagai berikut:

• Visi

“Menjadi aset nasional dalam bentuk jaringan retail waralaba yang

unggul dalam persaingan global”.

• Misi

“Meningkatkan pelayanan terbaik sehingga kepuasan pelanggan menjadi

sasaran utama yang harus dapat dipenuhi”.

58

Visi dan misi perusahaan juga didukung oleh motto dari Indomaret yakni “Mudah

dan Hemat” dan budaya perusahaan yakni,

“Dalam bekerja kami menjunjung tinggi nilai-nilai:

• Kejujuran, kebenaran, dan keadilan

• Kerja sama tim

• Kemajuan melalui inovasi yang ekonomis

• Kepuasan pelanggan”

59

3.1.3 Struktur Organisasi PT. Indomarco Prismatama

Gambar 3.1 Struktur Organisasi PT. Indomarco Prismatama

60

Setiap posisi dan bagian dalam perusahaan memiliki wewenang dan tanggung

jawabnya masing-masing dalam melaksanakan kegiatan perusahaan untuk

mencapai tujuan-tujuan yang diinginkan. Daftar wewenang dan tanggung jawab

masing-masing posisi dan bagian di PT. Indomarco Prismatama adalah sebagai

berikut:

1. Presiden Director

Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut:

a. Mengkoordinasi semua tanggung jawab direktur di bawahnya.

b. Mengarahkan dan mengawasi perkembangan perusahaan.

c. Menetapkan dan mengarahkan strategi bisnis perusahaan.

d. Mengendalikan dan mengawasi jalannya seluruh kegiatan

operasional perusahaan.

2. Internal Audit Director


a. Memastikan terlaksananya kebijakan perusahaan yang telah

ditetapkan di semua divisi.

b. Mengaudit dan memastikan apa yang seharusnya dijalankan sesuai

dengan sistem dan procedure yang dilaksanakan.

c. Menganalisa dan memberikan saran terhadap semua hal yang terjadi

di lapangan termasuk perkembangan bisnis yang ada.

61

3. Operation Director

Bertanggung jawab terhadap manajemen operasional dan pengembangan

bisnis perusahaan secara simultan serta bertanggung jawab membawahi

Region I, Region II, dan Marketing. Wewenang dan tanggung jawab

bagian-bagian yang disebutkan adalah sebagai berikut:

• Region I

Bertanggung jawab atas kegiatan para kepala cabang yang berada

di Jakarta I (Jakarta Barat, Jakarta Utara, dan sebagian Jakarta

Timur), Jakarta II (Bogor, Depok, sebagian Jakarta Selatan), dan

Bekasi (Cikarang, Cikampek).

• Region II

Bertanggung jawab atas kegiatan kepala cabang yang berada di

Semarang, Tangerang, Surabaya, Bandung.

• Marketing

Terdiri dari dua bagian yaitu sebagai berikut:

o Bagian yang berhubungan dengan supplier untuk

penyediaan barang dagangan yang ada di toko.

o Bagian yang berhubungan dengan waralaba toko yaitu

melakukan penjualan toko secara waralaba kepada investor.

62

4. Human Resources & Services Director


a. Mengatur dan mengelola Sumber Daya Manusia (SDM) yang ada.

b. Pengembangan SDM.

c. Karir dan perekrutan karyawan.

d. Pengadaan barang di luar barang dagangan (contoh : aktiva tetap)

e. Membawahi bagian-bagian berikut:

• Human Resources

o Melaksanakan penerimaan dan pengangkatan

karyawan.

o Melaksanakan evaluasi kerja karyawan.

• Personal and General Affair

o Bertanggung jawab untuk mengelola SDM yang

telah tersedia secara administrasi.

o Memberikan informasi kepada Education and

Training untuk peningkatan kinerja Sumber Daya

Manusia.

o Mendata dan memelihara harta perusahaan.

o Mengidentifikasikan kebutuhan pelatihan untuk

seluruh karyawan.

o Menyelenggarakan pelatihan.

o Mengevaluasi efektifitas pelatihan.

63

o Menciptakan hubungan kerja yang baik antara

karyawan dengan perusahaan.

• Education and Training

o Bertanggung jawab untuk pengembangan SDM

sesuai dengan kebutuhan perusahaan baik secara

internal maupun eksternal (misalnya, memanggil

trainer dari luar perusahaan).

• General Purchasing

o Bertanggung jawab melakukan pembelian barang-

barang kebutuhan operasional (aktiva tetap dan

barang-barang inventaris) perusahaan di luar barang

dagangan.

o Melakukan perbandingan harga dari minimal 2

supplier untuk mendapatkan barang-barang

operasional yang lebih murah dan berkualitas.

o Melaksanakan pembelian di luar barang dagangan

sesuai dengan permintaan dari seluruh bagian.

o Menerima dan mengevaluasi semua kontrak

pembelian di luar barang dagangan.

• Project Development

o Bertanggung jawab untuk melakukan renovasi toko

yang akan disewa atau dibeli oleh perusahaan atau

ter-waralaba agar sesuai dengan standar Indomaret.

64

o Membangun toko baru dan memperbaiki toko-toko

yang rusak.

5. Business Development Director


a. Mencari lokasi dalam upaya pengembangan perusahaan / group.

b. Merenovasi toko.

c. Pengembangan franchise.

d. Membawahi bagian-bagian berikut:

• Location Development

o Bertanggung jawab untuk mencari lokasi yang sesuai

dengan standar Indomaret.

• Franchise Development

o Bertanggung jawab untuk mencari investor untuk

menjadi ter-waralaba.

• Project & Renovation

o Bertanggung jawab untuk membangun dan

merenovasi toko yang sesuai dengan standar

Indomaret.

65

6. Finance Director

Bertanggung jawab terhadap administrasi keuangan dan pajak serta

membawahi bagian-bagian berikut:

• Finance & Administration

o Melaksanakan pekerjaan-pekerjaan administrasi perusahaan.

• Treasury

o Membayar gaji karyawan yang berada di level manager ke

atas.

o Melakukan hubungan dengan pihak perbankan.

• Taxation

o Melaksanakan perpajakan perusahaan yang sesuai dengan

ketentuan yang berlaku.

o Berhubungan langsung dengan kantor pajak.

• Controlling

o Melakukan pemastian agar tidak terjadi penyimpangan-

penyimpangan dari budget yang telah ditetapkan

sebelumnya. Apabila telah terjadi maka Controlling akan

mencari penyebab terjadinya penyimpangan tersebut.

o Mengontrol suatu proses kerja di cabang agar dapat lebih

efisien.

• Policies System

66

o Membuat suatu kerangka kerja dari sebuah divisi secara

sistematis sehingga dapat terkontrol dan sasaran perusahaan

dapat tercapai.

7. Merchandising Director


a. Menangani ketersediaan barang-barang dagangan

b. Membina hubungan yang baik dengan pemasok

c. Melakukan market survey secara berkala dan terinci terutama dalam

bidang retail

d. Mengevaluasi calon pemasok.

e. Evaluasi berkala terhadap pemasok.

f. Pengajuan keluhan atau pengembalian barang dagangan yang tidak

sesuai kepada pemasok

g. Untuk pelaksanaan tanggung jawab di atas lebih lanjutnya ditangani

oleh masing-masing bagian di bawah ini :

• Food Merchandising

• Non Food Merchandising

• Perishable Merchandising

• General Merchandising I

• General Merchandising II

• Regional Merchandising

• Merchandising Support and Development

67

8. Information and Development Director

Bertanggung jawab dalam pengadaan program komputer untuk setiap

departemen sehingga proses kerja menjadi lebih efisien (tidak padat karya).

Selain itu, Information and Development Director juga membawahi bagian

Software Development I, II, dan III yang bertanggung jawab dalam

pembuatan program atau aplikasi yang berbeda-beda. Contoh pekerjaan

dari masing-masing bagian adalah sebagai berikut:

• Software Development I

Contoh:

Pembuatan program untuk divisi Finance and Administration

• Software Development II

Contoh:

Pembuatan program untuk divisi Operation.

• Software Development III

Contoh:

Pembuatan program untuk divisi Merchandising.

68

Bagian-bagian lain yang dibawahinya adalah sebagai berikut:

• Data Processing

o Bertanggung jawab atas pemrosesan data-data yang ada.

• Technology Development

o Bertanggung jawab untuk pengembangan program-program

dengan teknologi atau hal-hal baru.

• Technical Support

o Bertanggung jawab terhadap hardware, jaringan, dan lain-

lain yang terkait dengan komputer.

69

3.2 Analisis Sistem yang Berjalan

3.2.1 Proses Bisnis Terkait Purchase Order

Gambar 3.2 Flow Chart Sistem yang Berjalan

70

Proses pembelian barang hingga menghasilkan purchase order pada PT.

Indomarco Prismatama dijelaskan sebagai berikut:

1. Jika suatu gerai Indomaret membutuhkan barang, maka gerai tersebut akan

meminta barang yang dibutuhkan kepada Distribution Centre (DC). Ada 13

buah DC yang ditempatkan sesuai dengan kawasan operasional yang sudah

ditentukan sehingga setiap gerai hanya akan dilayani oleh satu DC saja dan

sebaliknya setiap DC tentunya melayani ratusan gerai.

2. Permintaan barang dari seluruh gerai yang menjadi tanggung jawab

Distribution Centre (DC) bersangkutan akan diproses setiap harinya. DC

yang juga berfungsi sebagai gudang ini, akan terlebih dahulu memeriksa

ketersediaan barang di gudang. Jika barang yang diminta masih tersedia,

maka barang tersebut akan segera dikirimkan ke gerai Indomaret yang

membutuhkannya. Jika ternyata barang yang diminta sudah tidak tersedia,

maka DC akan mengeluarkan surat permintaan barang (PB) dan

mengirimkannya ke bagian merchandising. Surat PB ini berisikan daftar

permintaan barang oleh seluruh toko yang menjadi tanggung jawab DC

tersebut. Setiap DC biasanya mengirimkan satu PB, yang berisikan sekitar

3000 barang, kepada bagian merchandising setiap harinya. Dalam kasus

tertentu seperti menipisnya persediaan barang di gudang, DC dapat

mengeluarkan PB tanpa harus menunggu adanya permintaan dari gerai

yang menjadi tanggung jawabnya.

3. Bagian merchandising kemudian akan memproses setiap Permintaan

Barang (PB) ini dengan memecahnya menjadi beberapa usulan order (UO)

yang kemudian setiap UO ini akan diproses menjadi purchase order (PO)

71

yang ditujukan untuk satu atau lebih supplier. PB harus dipecah menjadi

beberapa PO dikarenakan daftar permintaan barang, yang terdapat di dalam

PB, disusun tanpa memperhatikan jenis barangnya yang pada kenyataannya

barang-barang tersebut sangat mungkin dipasok oleh supplier yang

berbeda-beda. Meskipun demikian, jika ada dua buah PB yang berisikan

permintaan atas barang yang sama, permintaan ini tidak akan digabungkan

dalam PO yang sama dikarena pada saat proses pengiriman barang,

supplier akan mengirimkan barang langsung kepada Distribution Centre

(DC) yang dituju tanpa melalui bagian merchandising. Akibatnya, sebuah

PO hanya mungkin berasal dari sebuah PB saja. Selain mengirimkan PO

kepada supplier, bagian merchandising juga akan mengirimkan salinan PO

tersebut kepada DC yang bersangkutan. Hal ini dilakukan agar nantinya

DC dapat mencocokkannya dengan barang-barang yang dikirim oleh

supplier.

4. Setelah menerima purchase order (PO) dari bagian merchandising,

supplier akan langsung menyiapkan dan mengirimkan barang yang diminta

ke DC yang bersangkutan. Jika barang yang dipesan tersedia, maka

supplier akan segera mengirimkannya ke DC yang dituju. Akan tetapi,

apabila barang yang diminta tersebut tidak tersedia maka supplier akan

menginformasikan hal ini kepada bagian merchandising dan barang yang

tidak tersedia tersebut akan dipesan kembali pada PO yang akan dikirim

selanjutnya.

5. Ketika barang-barang yang dikirim oleh supplier telah sampai di

Distribution Centre (DC), maka DC akan mengeluarkan surat Bukti Terima

72

Barang (BTB) dan menyerahkannya kepada pihak supplier sebagai bukti

bahwa barang telah diterima. Salinan dari surat BTB ini akan dikirimkan

kepada bagian merchandising untuk kemudian dicatat.

Jumlah barang yang dipesan oleh DC dalam usulan order (UO) secara umum tidak

akan sama dengan jumlah barang yang dipesan secara riil ke supplier melalui

purchase order (PO). Perbedaan jumlah barang yang sesungguhnya dibutuhkan

dan yang dipesan secara riil ini dikarenakan pemesanan barang oleh DC

merupakan kumpulan dari permintaan-permintaan gerai-gerai yang biasanya dalam

jumlah kecil sedangkan pemesanan barang yang dilakukan secara riil ke supplier

biasanya dalam jumlah yang relatif lebih besar untuk menekan harga modal. Oleh

sebab itu, pihak manajerial merasa perlu untuk mengetahui efektivitas dari

pemesanan suatu jenis barang barang kepada supplier. Informasi mengenai

efektivitas realisasi pemesanan ini dapat dilihat dari detail usulan order dan

purchase order serta selisihnya sehingga pihak manajerial dapat mengetahui

berapa besar persentase kelebihan barang pada setiap pemesanan yang dilakukan.

Informasi ini nantinya akan ditampilkan dalam laporan purchase order sehingga

laporan purchase order ini digunakan oleh pihak manajerial untuk memonitor atau

mengawasi proses pembelian barang yang sesungguhnya terjadi. Namun pada saat

ini, aplikasi yang digunakan untuk menghasilkan laporan ini mengalami masalah

berupa lamanya waktu yang dibutuhkan oleh aplikasi ini untuk menghasilkan

laporan. Jika aplikasi tersebut dijalankan untuk menghasilkan sebuah laporan,

maka user harus menunggu sekitar 1 jam atau lebih sampai laporan tesebut keluar.

73

Penulis akan melakukan analisis pada data-data yang dikumpulkan, dari hasil

survei dan wawancara yang telah dilakukan dengan pihak perusahaan, dari

beberapa aspek untuk menemukan penyebab utama masalah performance pada

aplikasi ditinjau dari sisi response time. Aspek-aspek yang akan dianalisis oleh

penulis, dalam rangka menemukan faktor utama penyebab masalah performance,

secara berturut-turut adalah sebagai berikut:

1. Aspek Data Model

Penulis akan melakukan analisis pada tabel-tabel database yang

digunakan terkait dengan aplikasi Reporting Purchase Order.

2. Aspek PL/SQL Code

Penulis akan melakukan analisis pada PL/SQL code yang digunakan di

aplikasi Reporting Purchase Order.

3. Aspek-aspek lainnya

Penulis akan melakukan analisis pada informasi-informasi, yang tidak

tergolong pada aspek data model dan aspek PL/SQL Code, yang diperoleh

melalui hasil wawancara.

3.2.2 Tabel-tabel yang Dipakai untuk Reporting Purchase Order

Jumlah tabel yang dipakai oleh sistem pembelian barang di PT. Indomarco

Prismatama sangatlah banyak sehingga penulis akan membatasi cakupan

analisisnya hanya sebatas pada tabel-tabel yang berkaitan dengan aplikasi

Reporting Purchase Order.

74

Dari data-data yang berhasil didapatkan, penulis menemukan bahwa data

model atau tabel-tabel yang digunakan oleh sistem tidak sesuai dengan standar

yang digunakan pada DBMS pada umumnya. Hal ini terlihat pada tidak

didefinisikannya primary key (PK) dan foreign key (FK) pada tabel-tabel tersebut.

Melalui proses wawancara lanjutan yang dilakukan oleh penulis kepada pihak PT.

Indomarco Prismatama, penulis mengambil kesimpulan bahwa struktur tabel yang

tanpa disertai PK dan FK ini sebagai akibat dari proses migrasi sistem yang

terdahulu yakni DBASE. Akibatnya, dalam menjaga relasi antar tabelnya, sistem

saat ini tidak melakukannya pada level database dengan PK-FK melainkan pada

level implementasi yakni pada aplikasi yang digunakan.

Meskipun demikian, penulis tetap merasa perlu untuk melakukan analisis

primary key dan foreign key pada tabel-tabel tersebut karena dengan mengetahui

primary key dan foreign key dari setiap tabel akan membantu pemahaman atas

relasi yang ada pada data model sistem yang sedang berjalan. Field-field yang

berhubungan dengan aplikasi reporting prurchase order pada tabel-tabel tersebut

beserta hasil analisis primary key dan foreign key-nya masing-masing adalah

sebagai berikut:

1. Tabel T_UNIT

Primary Key: FTKODE

Foreign Key: -

Keterangan:

Tabel ini berisi data tentang unit perusahaan. Primary key tabel ini adalah

FTKODE.

75

Field Keterangan Tipe Data

Jenis Ukuran

FTKODE Kode unit CHAR 1 BYTE

FTNAMA Nama unit VARCHAR2 30 BYTE

Tabel 3.1 Tabel T_UNIT

2. Tabel T_WILAYAH

Primary Key: FTKODE

Foreign Key: -

Keterangan:

Tabel ini berisi data tentang wilayah-wilayah toko di perusahaan.

Primary key tabel ini adalah FTKODE.


Jenis Ukuran

FTKODE Kode wilayah VARCHAR2 3 BYTE

FTNAMA Nama wilayah VARCHAR2 30 BYTE

Tabel 3.2 Tabel T_WILAYAH

3. Tabel T_CABANG

Primary Key: FTKODE

Foreign Key: FTKWIL, FTKSBU

Keterangan:

Tabel ini merupakan tabel yang berisi data tentang cabang perusahaan.

Primary key tabel ini adalah FTKODE. Pada tabel ini, terdapat foreign key

FTKWIL yang menghubungkan tabel T_CABANG dengan tabel

76

T_WILAYAH serta FTKSBU yang menghubungkan tabel T_CABANG

dan T_UNIT.


Jenis Ukuran

FTKODE Kode cabang VARCHAR2 4 BYTE

FTNAMA Nama cabang VARCHAR2 30 BYTE

FTKWIL Kode wilayah VARCHAR2 3 BYTE

FTKSBU Kode unit CHAR 1 BYTE

Tabel 3.3 Tabel T_CABANG

4. Tabel T_SUPPLIER

Primary Key: FTKODE

Foreign Key: -

Keterangan:

Tabel ini berisi data-data tentang supplier. Primary key pada tabel ini

adalah FTKODE.


Jenis Ukuran

FTKODE Kode supplier NUMBER 5

FTNAMA Nama supplier VARCHAR2 50 BYTE

Tabel 3.4 Tabel T_SUPPLIER

5. Tabel T_DIVISI

Primary Key: FTKODE

Foreign Key: -

Keterangan:

77

Tabel ini merupakan tabel divisi pada perusahaan yang menangani suatu

divisi produk. Primary key tabel ini adalah FTKODE.


Jenis Ukuran

FTKODE Kode divisi VARCHAR2 2 BYTE

FTNAMA Nama divisi VARCHAR2 30 BYTE

FTKMGR Kode manager VARCHAR2 15 BYTE

Tabel 3.5 Tabel T_DIVISI

6. Tabel T_DEPT

Primary Key: FTKODE

Foreign Key : FTKDIV

Keterangan:

Tabel ini merupakan tabel departemen produk pada perusahaan. Primary

key pada tabel ini adalah FTKODE. Foreign key pada tabel ini adalah

FTKDIV yang menghubungkan tabel ini dengan tabel T_DIVISI. Pada

tabel ini, terlihat redudansi pada field FTKMGR yang merupakan kode

manager divisi dan ada pada tabel T_DIVISI.


Jenis Ukuran

FTKODE Kode departemen VARCHAR2 2 BYTE

FTNAMA Nama departemen VARCHAR2 30 BYTE

FTKDIV Kode divisi VARCHAR2 2 BYTE

FTKMGR Kode manager VARCHAR2 15 BYTE

FTKSPV Kode supervisor VARCHAR2 15 BYTE

Tabel 3.6 Tabel T_DEPT

78

7. Tabel M_PRODUK

Primary Key: FMKODE

Foreign Key: FMKDIV, FMKDEP

Keterangan:

Tabel ini merupakan tabel master produk yang dijual perusahaan.

Primary key pada tabel ini adalah FMKODE. Foreign key pada tabel ini

adalah FMKDIV yang menghubungkan tabel M_PRODUK dan T_DIVISI

serta FMKDEP yang menghubungkan tabel M_PRODUK dan T_DEPT.

Padahal, dengan FMKDEP saja, suatu produk dapat ditentukan divisi

produknya karena pada tabel T_DEPT juga terdapat foreign key

penghubung ke tabel T_DIVISI.


Jenis Ukuran

FMKODE Kode produk NUMBER 8

FMMERK Merek produk VARCHAR2 15 BYTE

FMNAMA Nama produk VARCHAR2 30 BYTE

FMFLAV Flavour produk VARCHAR2 15 BYTE

FMKMSN Kemasan produk VARCHAR2 3 BYTE

FMSIZE Ukuran produk VARCHAR2 10 BYTE

FMKDIV Kode divisi VARCHAR2 2 BYTE

FMKDEP Kode departemen VARCHAR2 2 BYTE

Tabel 3.7 Tabel M_PRODUK

79

8. Tabel DD_PRODUK

Primary Key: FDKODE, FDKSBU

Foreign Key: FDKODE, FDKSBU

Keterangan:

Tabel ini merupakan tabel detail produk. Primary key tabel ini adalah

FDKODE dan FDKSBU yang juga merupakan foreign key penghubung

tabel ini dengan tabel M_PRODUK dan T_UNIT.


Jenis Ukuran

FDKODE Kode produk NUMBER 8

FDKSBU Kode unit CHAR 1 BYTE

FDFCRS Flag cursor warehouse VARCHAR2 1 BYTE

Tabel 3.8 Tabel DD_PRODUK

9. Tabel M_PLU_KONV

Primary Key: FMKSBU, FMKODE

Foreign Key: FMKSBU, FMKODE

Keterangan:

Tabel ini merupakan tabel yang berisi konversi kode produk dari unit-unit

perusahaan yang berbeda menjadi kode produk yang dipakai perusahaan.

Primary key tabel ini adalah FMKSBU dan FMKODE yang juga

merupakan foreign key penghubung tabel ini dengan tabel T_UNIT dan

M_PRODUK.

80


Jenis Ukuran

FMKSBU Kode unit CHAR 1 BYTE

FMKODE Kode produk NUMBER 8

FMKPLU Kode produk pada unit VARCHAR2 8 BYTE

Tabel 3.9 Tabel M_PLU_KONV

10. Tabel T_STATUS

Primary Key: FTKODE

Foreign Key: -

Keterangan:

Tabel ini merupakan tabel status produk. Primary key tabel ini adalah

FTKODE.


Jenis Ukuran

FTKODE Kode status VARCHAR2 2 BYTE

FTNAMA Nama status VARCHAR2 30 BYTE

FTFTBO Status produk boleh dipesan atau tidak CHAR 1 BYTE

Tabel 3.10 Tabel T_STATUS

11. Tabel D_REGION_PR

Primary Key: FDKODE, FDKSBU, FDKWIL

Foreign Key: FDKODE, FDKSBU, FDKWIL, FDKSTS

Keterangan:

Tabel ini berisi data tentang produk di wilayah yang ada. Primary key

tabel ini adalah FDKODE, FDKSBU, dan FDKWIL yang sekaligus

81

merupakan field foreign key penghubung tabel ini dengan tabel

M_PRODUK, T_UNIT, dan T_WILAYAH. Selain itu, terdapat foreign key

FDKSTS yang merupakan penghubung tabel D_REGION_PR dan

T_STATUS.


Jenis Ukuran



FDKWIL Kode wilayah VARCHAR2 3 BYTE

FDKSTS Kode status VARCHAR2 2 BYTE

FDKRTL Kode retail VARCHAR2 1 BYTE

Tabel 3.11 Tabel D_REGION_PR

12. Tabel MH_POORD

Primary Key : FHNOPO

Foreign Key : FHKSBU, FHKWIL, FHKCAB, FHKSUP, FHNOUO

Keterangan:

Tabel ini berisi data-data umum tentang Purchase Order. Primary key

tabel ini adalah FHNOPO yang merupakan nomor Purchase Order. Selain

itu, pada tabel ini, juga terdapat foreign key FHKSBU yang

menghubungkan tabel MH_POORD dan T_UNIT, FHKWIL yang

menghubungkan tabel MH_POORD dengan tabel T_WILAYAH,

FHKCAB yang menghubungkan tabel MH_POORD dengan tabel

T_CABANG, dan FHKSUP yang menghubungkan tabel MH_POORD

dengan tabel T_SUPPLIER. Selain itu, terdapat pula FHNOUO yang

82

merupakan primary key pada MD_ORDER. Di sini, redudansi dapat dilihat

dari field FHKSBU dan FHKWIL yang sebenarnya sudah ada pada tabel

T_CABANG sehingga seharusnya nilai FHKCAB sudah dapat digunakan

untuk mengetahui nilai FHKSBU dan FHKWIL.


Jenis Ukuran

FHNOPO Nomor PO VARCHAR2 9 BYTE

FHTGPO Tanggal PO DATE -

FHKSBU Kode unit CHAR 1 BYTE

FHKWIL Kode wilayah VARCHAR2 3 BYTE

FHKCAB Kode cabang VARCHAR2 4 BYTE

FHNOPB Nomor PB VARCHAR2 9 BYTE

FHTGPB Tanggal PB DATE -

FHTNIL Total nilai NUMBER 12, 2

FHTPPN Total PPN NUMBER 12, 2

FHTPPM Total PPNBM NUMBER 12, 2

FHTBTL Total botol NUMBER 12, 2

FHKSUP Kode supplier NUMBER 5

FHNOUO Nomor UO VARCHAR2 9 BYTE

Tabel 3.12 Tabel MH_POORD

13. Tabel MD_ORDER

Primary Key: FDNOUO, FDKODE

Foreign Key: FDNOPO, FDKODE, FDKSBU, FDKWIL, FDKCAB,

FDKSUP.

83

Keterangan:

Tabel ini berisi detail usulan order (UO). Primary key tabel ini adalah

FDNOUO dan FDKODE. Kedua field ini juga merupakan foreign key

penghubung tabel MH_POORD dan M_PRODUK. Selain itu ada pula

foreign key FDKSBU yang menghubungkan tabel MD_ORDER dan

T_UNIT, FDKWIL yang menghubungkan tabel MD_ORDER dengan tabel

T_WILAYAH, FDKCAB yang menghubungkan tabel MD_ORDER

dengan tabel T_CABANG, dan FDKSUP yang menghubungkan tabel

MD_ORDER dengan tabel T_SUPPLIER. Dilihat dari foreign key ini, kita

dapat melihat adanya redudansi karena pada tabel MH_POORD terdapat

foreign key FDKSBU, FDKWIL, FDKCAB dan FDKSUP. Selain itu

redudansi juga terlihat dari adanya field FDNOPB, FDTGPB dan FDTGPO

yang terdapat pada tabel MH_POORD dan field FDKDIV yang terdapat

pada tabel M_PRODUK.


Jenis Ukuran

FDNOUO Nomor UO VARCHAR2 9 BYTE


FDISIP Satuan isi NUMBER 6

FDSATB Satuan barang VARCHAR2 3 BYTE

FDTGUO Tanggal UO DATE



FDKCAB Kode cabang VARCHAR2 4 BYTE

FDQTYB Jumlah barang NUMBER 6

FDQTYF Jumlah barang bonus NUMBER 5

84

FDHSAT Harga satuan NUMBER 12, 2

FDDISC Diskon NUMBER 12, 2

FDTNIL Total nilai NUMBER 12, 2

FDTPPN Total PPN NUMBER 12, 2

FDTPPM Total PPNBM NUMBER 12, 2

FDTBTL Total botol NUMBER 12, 2

FDKSUP Kode supplier NUMBER 5

FDNOPO Nomor PO VARCHAR2 9 BYTE

FDTGPO Tanggal PO DATE -

FDNOPB Nomor PB VARCHAR2 9 BYTE

FDTGPB Tanggal PB DATE -

FDKDIV Kode divisi VARCHAR2 2 BYTE

FDRCID Status delete CHAR 1 BYTE

Tabel 3.13 Tabel MD_ORDER

14. Tabel T_PO_TYPE

Primary Key: FTNOPO

Foreign Key: FTNOPO, FTKODE

Keterangan:

Tabel ini berisi data-data tentang jenis Purchase Order. Primary key tabel

ini adalah FTNOPO yang sekaligus merupakan foreign key penghubung

tabel T_PO_TYPE dan MH_POORD. Foreign key yang lain yaitu

FTKODE merupakan penghubung tabel T_PO_TYPE dan M_PRODUK.

Ada 2 jenis PO yang ada yaitu ‘PO Seasonal’ yang merupakan jenis PO

musiman (bukan PO rutin) dan ‘GOD’ yang merupakan jenis PO yang

mendapat Grand Opening Discount. Selain kedua jenis PO ini, ada PO

rutin yang merupakan pemesanan barang rutin.

85


Jenis Ukuran

FTNOPO Nomor PO VARCHAR2 9 BYTE

FTKODE Kode produk NUMBER 8

FTPOTP Jenis PO VARCHAR2 100 BYTE

Tabel 3.14 Tabel T_PO_TYPE

15. Tabel MD_TSTOCK

Primary Key: FDNOPO, FDKODE

Foreign Key: FDNOPO, FDKODE, FDKSBU, FDKWIL, FDKCAB,

FDKSUP

Keterangan:

Tabel ini berisi data realisasi produk yang dipesan melalui PO. Tidak

semua produk yang dipesan pada PO bisa diperoleh, maka dari itu tabel ini

akan mencatat realisasinya. Primary key pada tabel ini adalah FDNOPO

dan FDKODE. Kedua field ini juga merupakan foreign key penghubung

tabel MH_POORD dan M_PRODUK. Selain itu ada pula foreign key

FDKSBU yang menghubungkan tabel MD_TSTOCK dan T_UNIT,

FDKWIL yang menghubungkan tabel MD_TSTOCK dengan tabel

T_WILAYAH, FDKCAB yang menghubungkan tabel MD_TSTOCK

dengan tabel T_CABANG, dan FDKSUP yang menghubungkan tabel

MD_TSTOCK dengan tabel T_SUPPLIER. Dilihat dari foreign key ini,

kita dapat melihat adanya redudansi lagi karena pada tabel MH_POORD

terdapat foreign key FDKSBU, FDKWIL, FDKCAB dan FDKSUP.

86


Jenis Ukuran





FDKCAB Kode cabang VARCHAR2 4 BYTE

FDQTYR Jumlah barang real NUMBER 12

FDTNIL Total nilai NUMBER -

FDTPPN Total PPN NUMBER 12, 2

FDTPPM Total PPM NUMBER 12, 2

FDTBTL Total botol NUMBER 12, 2

FDKSUP Kode supplier NUMBER 5

FDNBTB Nomor BTB VARCHAR2 9 BYTE

FDTBTB Tanggal BTB DATE -

Tabel 3.15 Tabel MD_TSTOCK

16. Tabel MD_GOD

Primary Key: FDNOPO, FDKODE

Foreign Key: FDNOPO, FDKODE, FDNOUO

Keterangan:

Tabel ini berisi data produk yang mendapatkan diskon Grand Opening.

Primary key pada tabel ini adalah FDNOPO dan FDKODE yang juga

merupakan foreign key penghubung dengan tabel MH_POORD dan

M_PRODUK. Selain itu, ada pula FDNOUO yang merupakan primary key

pada tabel MD_ORDER.

87


Jenis Ukuran



FDPDIS Potongan diskon NUMBER 5, 2

FDNILD Nilai diskon NUMBER 12, 2

FDNOUO Nomor UO VARCHAR2 9 BYTE

Tabel 3.16 Tabel MD_GOD

17. Tabel T_LAP_REAL_PO_I_DETAIL

Primary Key: FTNOPO, FTKODE, FTUSER

Foreign Key: FTNOPO, FTKODE, FTKSBU, FTKWIL, FTKCAB,

FTKSUP, FTKDIV, FTKDEP

Keterangan:

Tabel ini berisi detail realisasi PO. Tabel ini merupakan tabel yang isinya

diambil dari isi tabel-tabel lain. Primary key tabel ini adalah FTNOPO,

FTKODE dan FTUSER yang juga merupakan foreign key penghubung

tabel MH_POORD dan M_PRODUK. Selain itu ada pula foreign key

FTKSBU yang merupakan penghubung dengan tabel T_UNIT, FTKWIL

yang merupakan penghubung dengan tabel T_WILAYAH, FTKCAB yang

merupakan penghubung dengan tabel T_CABANG, FTKSUP yang

merupakan penghubung dengan tabel T_SUPPLIER.

88


Jenis Ukuran

FTNOPO Nomor PO VARCHAR2 9 BYTE


FTNAMA Nama produk VARCHAR2 100 BYTE

FTSATB Satuan barang VARCHAR2 30 BYTE

FTKSBU Kode unit CHAR 1 BYTE

FTKWIL Kode wilayah VARCHAR2 3 BYTE

FTKCAB Kode cabang VARCHAR2 4 BYTE

FTQTYB Jumlah barang NUMBER 8

FTTNIL Total nilai NUMBER 14, 4

FTQTYR Jumlah barang real NUMBER 8

FTNILR Total nilai real NUMBER 14, 4

FTQTYS Selisih jumlah barang NUMBER 8

FTNILS Selisih total nilai NUMBER 14, 4

FTNMDM Nama departemen VARCHAR2 15

FTKTAG Kode status barang VARCHAR2 2

FTKSUP Kode supplier NUMBER 5

FTTGPO Tanggal PO DATE -

FTKDIV Kode divisi VARCHAR2 2 BYTE

FTKDEP Kode departemen VARCHAR2 2 BYTE

FTTGUP Tanggal update DATE -

FTUSER Kode user VARCHAR2 15 BYTE

DISKON_GO Diskon Grand Opening NUMBER -

Tabel 3.17 Tabel T_LAP_REAL_PO_I_DETAIL

89

18. TABEL T_TAG_LAP

Primary Key: FTKODE, FTUSER

Foreign Key: FTKODE

Keterangan:

Tabel ini merupakan tabel yang berisi kode status barang serta nama user.

Primary key pada tabel ini adalah FTKODE dan FTUSER. Sedangkan

foreign key pada tabel ini adalah FTKODE yang menghubungkan tabel

T_TAG_LAP dengan tabel T_STATUS. Jika seorang user tidak terdaftar di

sini, maka user tersebut dapat mengakses semua status barang yang ada.


Jenis Ukuran

FTKODE Kode status barang VARCHAR2 2 BYTE


Tabel 3.18 Tabel T_TAG_LAP

19. Tabel T_PLU_LAP

Primary Key: FTKODE, FTUSER

Foreign Key: FTKODE

Keterangan:

Tabel ini merupakan tabel sementara yang berisi kode barang dan nama

user. Primary key pada tabel ini adalah FTKODE dan FTUSER. Sedangkan

foreign key pada tabel ini adalah FTKODE yang menghubungkan tabel

T_TAG_LAP dengan tabel M_PRODUK.

90


Jenis Ukuran



Tabel 3.19 Tabel T_PLU_LAP

Pada tabel-tabel di atas, ada beberapa index yang dibuat, yaitu sebagai

berikut:

Nama Tabel Nama Index Kolom-kolom

yang di-index

T_UNIT T_UNIT_FTKODE_PK FTKODE

T_CABANG T_CABANG_FTKODE_PK FTKODE

T_CABANG_IDX1 FTKODE,

FTKSBU

T_CABANG_IDX2 FTKSBU,

FTKWIL

T_SUPPLIER T_SUPPLIER_FTKODE_PK FTKODE

T_DIVISI T_DIVISI_FTKODE_PK FTKODE

T_DEPT T_DEPT_FTKODE_PK FTKODE

M_PRODUK DEP_IDX FMKDEP

M_PRODUK_FMKODE_PK FMKODE

DIV_IDX FMKDIV

DD_PRODUK DD_PRODUK_PK FDKODE,

FDKSBU

MH_POORD MH_POORD_PK FHNOPO

MH_POORD_TGPO FHTGPO

MH_POORD_SUPP FHKSUP

MH_POORD_ORD_REAL FHTGPO,

FHKSBU,

91

FHKSUP,

FHKCAB,

FHKWIL

MD_ORDER MD_ORDER_PK FDNOUO,

FDKODE

MD_ORDER_IDX1 FDTGPB

MD_ORDER_IDX2 FDNOPB

MD_ORDER_IDX FDKSBU,

FDKWIL,

FDKCAB

MD_ORDER_NOPO FDNOPO

MD_ORDER_TGPO FDTGPO

MD_ORDER_SUPP FDKSUP

MD_ORDER_FDKODE FDKODE

MD_TSTOCK MD_TSTOCK_PK FDNOPO,

FDKODE

MD_TSTOCK_CAB FDKCAB

MD_TSTOCK_SBU FDKSBU

MD_TSTOCK_SUPP FDKSUP

T_LAP_REAL_PO_I_DETAIL T_LAP_REAL_PO_I_DETAIL_PK FTNOPO,

FTKODE,

FTUSER

T_TAG_LAP T_TAG_LAP_PK FTKODE,

FTUSER

T_PLU_LAP T_PLU_LAP_PK FTKODE,

FTUSER

Tabel 3.20 Tabel Index yang Digunakan

92

Relationship atau hubungan antar tabel-tabel di atas dapat dilihat pada tabel

relationship berikut:

Tabel Multiplicity Relationship Tabel Multiplicity

T_UNIT

1..1 Memiliki

cabang

T_CABANG 1..*

1..1 Memiliki

detail produk

DD_PRODUK 1..*

1..1 Memiliki

kode barang

M_PLU_KONV 1..*

1..1 Memiliki

detail produk

wilayah

D_REGION_PR 1..*

1..1 Memiliki

master

purchase

order

MH_POORD 1..*

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..1 Memiliki

detail

purchase

order

MD_TSTOCK 1..*

1..1 Memiliki

realisasi

order

T_LAP_REAL_PO_I_DETAIL 1..*

T_WILAYAH 1..1 Memiliki

cabang

T_CABANG 1..*

1..1 Memiliki

detail produk

D_REGION_PR 1..*

93

wilayah

1..1 Memiliki

master

purchase

order

MH_POORD 1..*

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..1 Memiliki

detail

purchase

order

MD_TSTOCK 1..*

1..1 Memiliki

realisasi

order


T_CABANG 1..1 Memiliki

master

purchase

order

MH_POORD 1..*

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..1 Memiliki

detail

purchase

order

MD_TSTOCK 1..*

1..1 Memiliki

realisasi

order


T_SUPPLIER 1..1 Memiliki

master

MH_POORD 1..*

94

purchase

order

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..1 Memiliki

detail

purchase

order

MD_TSTOCK 1..*

1..1 Memiliki

realisasi

order


T_DIVISI 1..1 Memiliki

departemen

T_DEPT 1..*

1..1 Memiliki

master

produk

M_PRODUK 1..*

1..1 Memiliki

realisasi

order


T_DEPT 1..1 Memiliki

master

produk

M_PRODUK 1..*

1..1 Memiliki

realisasi

order


M_PRODUK

1..1 Memiliki

detail produk

DD_PRODUK 1..*

1..1 Memiliki

kode produk

unit

M_PLU_KONV 1..*

95

1..1 Memiliki

detail produk

wilayah

D_REGION_PR 1..*

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..* Memiliki

jenis PO

T_PO_TYPE 1..1

1..1 Memiliki

detail

purchase

order

MD_TSTOCK 1..*

1..1 Memiliki

diskon GO

MD_GOD 1..*

1..1 Memiliki

realisasi

order


1..1 Memiliki

akses user

T_PLU_LAP 1..*

T_STATUS

1..1 Memiliki

detail produk

wilayah

D_REGION_PR 1..*

1..1 Memiliki

akses user

T_TAG_LAP 1..*

MH_POORD

1..1 Memiliki

detail usulan

order

MD_ORDER 1..*

1..1 Memiliki

jenis PO

T_PO_TYPE 1..1

1..1 Memiliki

detail

MD_TSTOCK 1..*

96

purchase

order

1..1 Memiliki

diskon GO

MD_GOD 1..*

1..1 Memiliki

realisasi

order


MD_ORDER 1..1 Memiliki

diskon GO

MD_GOD 1..1

Tabel 3.21 Tabel Relationship antar tabel

3.2.3 Aplikasi Reporting Purchase Order

Aplikasi Reporting Purchase Order digunakan untuk menghasilkan laporan

tentang realisasi dari purchase order. Laporan realisasi PO ini dibutuhkan untuk

membandingkan usulan order dengan realisasi pemesanannya melalui purchase

order. Realisasi pemesanan barang ini akan ditampilkan pada laporan purchase

order yang berisikan daftar detail barang yang menjadi usulan order dan yang

sudah dipesan pada purchase order serta selisihnya. Jadi laporan purchase order

merupakan laporan yang digunakan untuk memonitor atau mengawasi proses

pembelian barang yang sesungguhnya terjadi.

Aplikasi Reporting Purchase Order ini dapat diakses dan digunakan oleh

semua pengguna sistem untuk menghasilkan laporan PO kapan saja. Akan tetapi

dari hasil wawancara yang telah dilakukan, penulis menemukan bahwa aplikasi ini

digunakan secara periodik yakni hanya sekali setiap bulannya dan jumlah

penggunanya kurang lebih hanya sepuluh user yang merupakan clerk pada bagian

Technical Support. Masalah kelambatan pada aplikasi selalu dialami, bahkan

97

ketika aplikasi ini dijalankan pada waktu yang bukan peak time dan hanya ada satu

user yang sedang menggunakan aplikasi ini meskipun user ini mengakses langsung

dari kantor pusat.

Tabel utama yang digunakan oleh aplikasi Reporting Purchase Order

untuk menghasilkan laporan adalah tabel T_LAP_REAL_PO_I_DETAIL. Tabel

ini berisikan data-data yang merupakan hasil summary dari beberapa tabel lainnya.

Proses summary dari beberapa tabel lain dan memasukkannya ke dalam tabel

T_LAP_REAL_PO_I_DETAIL dapat dilakukan dengan menjalankan procedure

LAP_REAL_PO_I_OPU_DETAIL terlebih dahulu.

Sebuah view bernama VU_LAP_REAL_PO_ITEM dibuat untuk membantu

mengurangi kompleksitas query yang berisikan banyak proses join dari berbagai

tabel, yakni MD_ORDER, D_REGION_PR, T_STATUS, M_PRODUK, dan

T_PO_TYPE, yang kemudian akan digunakan oleh procedure

LAP_REAL_PO_I_OPU_DETAIL dalam proses pemasukan data ke dalam tabel

T_LAP_REAL_PO_I_DETAIL.

98

Skema tabel pembentuk view VU_LAP_REAL_PO_ITEM adalah sebagai berikut:

VU_LAP_REAL_PO_ITEM

FDNOUOFDKODEFDISIPFDSATBFDTGUOFDKSBUFDKWILFDKCABFDQTYBFDQTYFFDHSATFDDISCFDTNILFDTPPNFDTPPMFDTBTLFDKSUPFDNOPOFDTGPOFDNOPBFDTGPBFDKDIVFDRCIDFMKDIVFMKDEPFMNAMAFDKSTSFTFTBOPO_TYPE

M_PRODUK

PK FMKODE

FMMERKFMNAMAFMFLAVFMKMSNFMSIZEFMKDIVFMKDEP

T_STATUS

PK FTKODE

FTNAMAFTFTBO

D_REGION_PR

PK FDKODEPK FDKSBUPK FDKWIL

FDKSTSFDKRTL

T_PO_TYPE

PK FTNOPOPK FTKODE

FTPOTP

MD_ORDER

PK FDNOUOPK FDKODE

FDISIPFDSATBFDTGUOFDKSBUFDKWILFDKCABFDQTYBFDQTYFFDHSATFDDISCFDTNILFDTPPNFDTPPMFDTBTLFDKSUPFDNOPOFDTGPOFDNOPBFDTGPBFDKDIVFDRCID

Gambar 3.3 Skema Tabel Pembentuk View VU_LAP_REAL_PO_ITEM

99

Sedangkan skema pembentukan tabel T_LAP_REAL_PO_I_DETAIL adalah

sebagai berikut:

T_LAP_REAL_PO_I_DETAIL

PK FTNOPOPK FTKODEPK FTUSER

FTNAMAFTSATBFTKSBUFTKWILFTKCABFTQTYBFTTNILFTQTYRFTNILRFTQTYSFTNILSFTNMDMFTKTAGFTKSUPFTTGPOFTKDIVFTKDEPFTTGUPDISKON_GO

VU_LAP_REAL_PO_ITEM

FDNOUOFDKODEFDISIPFDSATBFDTGUOFDKSBUFDKWILFDKCABFDQTYBFDQTYFFDHSATFDDISCFDTNILFDTPPNFDTPPMFDTBTLFDKSUPFDNOPOFDTGPOFDNOPBFDTGPBFDKDIVFDRCIDFMKDIVFMKDEPFMNAMAFDKSTSFTFTBOPO_TYPE

T_DEPT

PK FTKODE

FTNAMAFTKDIVFTKMGRFTKSPV

MD_GOD

PK FDNOPOPK FDKODE

FDPDISFDNILDFDNOUO

MD_TSTOCK

PK FDNOPOPK FDKODE

FDKSBUFDKWILFDKCABFDQTYRFDTNILFDTPPNFDTPPMFDTBTLFDKSUPFDNBTBFDTBTB

Gambar 3.4 Skema Pembentukan Tabel T_LAP_REAL_PO_I_DETAIL

100

Procedure LAP_REAL_PO_I_OPU_DETAIL yang digunakan dapat

dilihat pada lampiran (L1 – L14). Procedure ini akan meminta parameter-

parameter, yang harus diisi oleh user, yang nantinya akan digunakan sebagai

parameter dalam memasukkan data ke dalam tabel. Parameter-parameter yang

diminta pada procedure ini adalah sebagai berikut:

1. p_ksbu1 dan p_ksbu2

Parameter ini berisi kode unit perusahaan.

2. p_kwil

Paramater ini berisi kode wilayah.

3. p_kcab1 dan p_kcab2

Parameter ini berisi kode cabang. Jika salah satu parameter ini berisi

NULL, maka dipilihlah kode cabang yang paling kecil dan paling besar

dari tabel t_cabang. Dengan demikian, laporan yang dihasilkan berasal dari

semua cabang yang ada di suatu wilayah tertentu.

4. p_supp1 dan p_supp2

Parameter ini berisi kode supplier. Sama seperti parameter kode cabang

(p_kcab1 dan p_kcab2), jika salah satu parameter ini berisi NULL, maka

dipilihlah kode supplier yang paling kecil dan paling besar dari tabel

t_supplier.

101

5. p_date1 dan p_date2

Parameter ini merupakan parameter jangka waktu PO yang diinginkan.

6. p_tag

Parameter ini merupakan parameter status barang yang ingin dilihat. Ada

dua jenis parameter ini yaitu ‘A’ dan ‘N’. Parameter ini diisi ‘A’ jika user

ingin melihat pemesanan untuk barang yang aktif. Status barang tersebut

disebut aktif jika field ftftbo pada tabel t_status tidak bernilai ‘Y’. Nilai ‘Y’

pada field ftftbo berarti barang tersebut tidak boleh dipesan. Sebaliknya,

jika nilai pada field ftftbo sama dengan NULL atau bernilai ‘N’, maka

barang tersebut aktif dan bisa dipesan. Untuk itu, jika ingin melihat

pemesanan barang yang dahulu bisa dipesan tetapi sekarang tidak bisa

karena alasan-alasan tertentu maka parameter p_tag harus diisi ‘N’.

Selain itu, jika user yang menjalankan procedure ini terdaftar di dalam

tabel t_tag_lap yang merupakan tabel untuk membatasi akses user terhadap

status barang tertentu, maka status barang tersebut juga harus dilihat,

apakah dapat diakses oleh user tersebut atau tidak.

7. p_all

Parameter ini bisa diisi ‘Y’ atau ‘N’. Jika diisi ‘Y’, maka tidak perlu

dilakukan pengaksesan pada t_plu_lap untuk melihat kode barang yang

dapat diakses user tersebut. Jika diisi ‘N’, maka akan dilakukan

pengaksesan pada t_plu_lap untuk melihat kode barang apa saja yang dapat

diakses user tersebut.

102

8. p_usr

Parameter ini merupakan parameter user yang berfungsi untuk menandai

record yang dimasukkan oleh user tersebut. Hal ini dimaksudkan agar

ketika aplikasi dijalankan untuk menghasilkan laporan, query yang

dilakukan pada tabel T_LAP_REAL_PO_I_DETAIL hanya dilakukan pada

record yang sesuai dengan parameter user yang diisikan. Jika user yang

sama ingin menghasilkan laporan dengan parameter yang berbeda,

misalnya kode wilayah yang berbeda dari laporan sebelumnya, maka user

tersebut harus menjalankan procedure LAP_REAL_PO_I_OPU_DETAIL

lagi. Procedure ini kemudian akan terlebih dahulu menghapus semua

record yang dimiliki oleh user tersebut pada tabel

T_LAP_REAL_PO_I_DETAIL, kemudian baru memasukkan data baru

yang diinginkan. User dapat melihat laporan baru ini dengan menjalankan

aplikasi lagi.

9. p_warehouse

Jika parameter ini diisi dengan nilai ‘Y’ maka setiap barang pada unit

tertentu akan dilihat kolom fdfcrs yang dimilikinya pada tabel dd_produk.

Jika kolom fdfcrs berisi ‘Y’, maka barang tersebut dapat dimasukkan ke

T_LAP_REAL_PO_I_DETAIL. Jika parameter diisi ‘N’ atau NULL, maka

pengaksesan tabel dd_produk tidak diperlukan.

103

10. p_retail

Jika parameter ini diisi ‘Y’ maka setiap barang pada unit dan wilayah

tertentu akan dilihat kolom fdkrtl yang dimilikinya pada tabel d_region_pr.

Jika kolom fdkrtl berisi ‘Y’, maka barang tersebut dapat dimasukkan ke

T_LAP_REAL_PO_I_DETAIL. Jika parameter tidak diisi ‘Y’, maka

pengaksesan tabel d_region_pr tidak diperlukan.

11. p_potype

Parameter ini merupakan parameter jenis PO. Jika diisi ‘A’, maka jenis

PO yang diinginkan adalah jenis PO biasa, bukan ‘PO Seasonal’ atau

‘GOD’. Jika diisi ‘B’, maka jenis PO yang diinginkan adalah PO ‘GOD’

dan jika diisi ‘C’ maka jenis PO yang diinginkan adalah ‘PO Seasonal’.

Procedure LAP_REAL_PO_I_OPU_DETAIL juga menggunakan beberapa

cursor yakni sebagai berikut:

1. Cursor cur1

Cursor ini mengakses data pada view VU_LAP_REAL_PO_ITEM

dengan menggunakan parameter p_ksbu1, p_ksbu2, p_kwil, p_cab1,

p_cab2, p_supp1, p_supp2, p_date1, dan p_date2. Cursor ini menghasilkan

data tanpa memperhatikan user dan jenis PO.

104

2. Cursor cur2



p_cab2, p_supp1, p_supp2, p_date1, dan p_date2. Cursor ini menghasilkan

data tanpa memperhatikan jenis PO tetapi melakukan pengaksesan pada

tabel t_plu_lap untuk melihat kode barang yang bisa diakses oleh user

dengan menggunakan p_usr.

3. Cursor cur3



p_cab2, p_supp1, p_supp2, p_date1, p_date2, dan p_potype. Cursor ini

menghasilkan data tanpa memperhatikan user tetapi berdasarkan jenis PO

tertentu.

4. Cursor cur4



p_cab2, p_supp1, p_supp2, p_date1, p_date2, dan p_potype. Cursor ini

menghasilkan data dengan berdasarkan pada jenis PO tertentu dan

melakukan pengaksesan pada tabel t_plu_lap untuk melihat kode barang

yang bisa diakses oleh user dengan menggunakan p_usr.

105

5. Cursor warehouse

Cursor ini mengakses data pada tabel dd_produk untuk mengetahui

apakah suatu barang terdaftar di sana sebagai barang warehouse.

6. Cursor retail

Cursor ini mengakses data pada tabel d_region_pr untuk mengetahui

apakah suatu barang terdaftar di sana sebagai barang retail.

Cara kerja dari procedure LAP_REAL_PO_I_OPU_DETAIL adalah

dengan membuka salah satu cursor dari cur1, cur2, cur3 atau cur4 berdasarkan

parameter p_all, dan p_potype dengan ketentuan-ketentuan berikut:

1. Jika p_all = ‘Y’ dan p_potype =’A’, maka cursor yang diakses adalah

cursor cur1.

2. Jika p_all = ‘Y’ dan p_potype bernilai ‘B’ atau ‘C’, maka cursor yang

diakses adalah cursor cur3.

3. Jika p_all tidak bernilai ‘Y’ dan p_potype =’A’, maka cursor yang diakses

adalah cursor cur2.

4. Jika p_all tidak bernilai ‘Y’ dan p_potype bernilai ‘B’ atau ‘C’, maka

cursor yang diakses adalah cursor cur4.

Akan dilakukan proses validasi pada setiap record yang diakses melalui cursor

di atas sesuai parameter lain yang dimasukkan. Jika record tersebut lolos uji

validasi, maka record tersebut akan dimasukkan ke tabel

T_LAP_REAL_PO_I_DETAIL. Proses validasi ini akan terus dijalankan hingga

106

record terakhir telah diakses cursor. Proses validasi yang dilakukan adalah sebagai

berikut:

1. Jika p_tag =’A’, tetapi field ftftbo pada record bernilai ‘Y’, maka record ini

tidak dimasukkan.

2. Jika p_tag =’N’, tetapi field ftftbo pada record bernilai NULL atau ‘N’,

maka record ini tidak dimasukkan.

3. Jika p_usr ada pada tabel t_tag_lap, tetapi field fdksts pada record tidak

sesuai dengan ftkode yang dimiki user pada tabel tersebut, maka record ini

tidak dimasukkan.

4. Jika p_warehouse = ‘Y’, maka diakseslah cursor warehouse untuk

menemukan kode barang dan kode unit pada record yang sama dengan

kode barang dan kode unit pada tabel dd_produk yang mempunyai nilai

fdfcrs = ‘Y’. Jika tidak ditemukan, maka record ini tidak dimasukkan.

5. Jika p_retail = ‘Y’, maka diakseslah cursor retail untuk menemukan kode

barang, kode unit dan kode wilayah pada record yang sama dengan kode

barang, kode unit dan kode wilayah pada tabel dd_produk yang mempunyai

nilai fdkrtl = ‘Y’. Jika tidak ditemukan, maka record ini tidak dimasukkan.

Dari code procedure di atas, penulis menemukan adanya beberapa PL/SQL code

yang tidak digunakan secara efisien. Penggalan PL/SQL code yang dimaksud

adalah sebagai berikut:

1. Adanya proses delete terlebih dahulu untuk menghapus data pada tabel

T_LAP_REAL_PO_I_DETAIL yang pernah dimasukkan user sebelumnya

baru kemudian proses insert data yang baru dijalankan. Algoritma delete-

107

insert yang dipakai pada procedure ini sangatlah tidak efisien karena ketika

user ingin menghasilkan sebuah laporan baru bahkan dengan hanya satu

parameter yang berbeda, proses delete dan insert ini harus dijalankan

kembali. Selain itu, jika ada beberapa user yang ingin menghasilkan

laporan yang sesungguhnya sama, setiap user harus tetap menjalankan

procedure ini masing-masing secara terpisah. Hal ini harus dilakukan

karena pada saat akan menghasilkan laporan, parameter user yang

bersangkutan harus diisi dan tabel T_LAP_REAL_PO_I_DETAIL hanya

akan diakses berdasarkan user yang mengisi tabel ini melalui procedure.

Hal ini tercermin pada penggalan PL/SQL code berikut:

PROCEDURE LAP_REAL_PO_I_OPU_DETAIL(...) is ... BEGIN

delete from T_LAP_REAL_PO_I_DETAIL where ftuser=p_usr; ... Loop ... if p_potype = 'B' then ... insert into T_LAP_REAL_PO_I_DETAIL(...) values(...); ... end if; if p_potype = 'A' or p_potype = 'C' then ... insert into T_LAP_REAL_PO_I_DETAIL(...) values(...); ... end if; ... End loop;

... End;

108

2. Adanya proses looping yang tidak tepat pada procedure tersebut.

Contohnya seperti pada penggalan PL/SQL code berikut:

Penggalan PL/SQL code di atas berfungsi untuk mencari nilai fdqtyr dan

fdtnil yang tersimpan di tabel md_tstock di mana fdnopo dan fdkode di

tabel md_tstock sama dengan fdnopo dan fdkode pada cursor yang diakses.

Akan tetapi, proses looping di atas sesungguhnya tidak dibutuhkan karena

suatu fdnopo dan fdkode pada cursor sudah pasti hanya mempunyai satu

pasangan fdnopo dan fdkode pada tabel md_tstock.

Hal yang serupa juga terjadi pada penggalan PL/SQL code berikut:

v_qtyr:=0; v_nilr:=0; for x in(select nvl(fdqtyr,0) fdqtyr, nvl(fdtnil,0)+nvl(fdtppn,0)+

nvl(fdtppm,0)+nvl(fdtbtl,0) fdtnil from md_tstock

where fdnopo=cur_rec.fdnopo and fdkode=cur_rec.fdkode)

loop v_qtyr:=x.fdqtyr; v_nilr:=x.fdtnil; end loop;

v_mdm:=null; for x in(select ftkmgr from t_dept where ftkode=cur_rec.fmkdep) loop v_mdm:=x.ftkmgr; end loop;

109

Penggalan code di atas berfungsi untuk mencari manager dari departemen

produk yang sedang diakses cursor. Akan tetapi, proses looping tersebut

tidak dibutuhkan karena manager suatu departemen hanya terdiri dari satu

orang saja.

3. Adanya proses join yang kompleks pada procedure tersebut. Awalnya,

proses join dilakukan pada saat pengaksesan view

VU_LAP_REAL_PO_ITEM. Setelah itu, untuk mengetahui nilai real atau

diskon yang diberikan, proses join akan dilakukan lagi. Selain itu, untuk

memeriksa apakah setiap record yang diakses akan dimasukkan ke tabel

T_LAP_REAL_PO_I_DETAIL atau tidak, proses join ke tabel-tabel lain

untuk proses validasi juga akan dilakukan. Setelah data dimasukkan pada

tabel T_LAP_REAL_PO_I_DETAIL, proses join dilakukan lagi untuk

menghasilkan laporan. Proses-proses join ini tentunya membutuhkan waktu

yang tidak sedikit.

Setelah menjalankan procedure ini, maka user baru dapat menghasilkan

laporan yang diinginkan. Dalam proses menghasilkan laporan, aplikasi ini tidak

hanya mengakses tabel T_LAP_REAL_PO_I_DETAIL tetapi tabel-tabel lainnya

seperti T_UNIT, T_SUPPLIER, T_CABANG, dan M_PLU_KONV juga akan

diakses. Pada saat proses pembuatan laporan dijalankan, aplikasi ini akan meminta

parameter user untuk dimasukkan oleh pengguna. Parameter ini akan digunakan

sebagai filter ketika melakukan query pada tabel T_LAP_REAL_PO_I_DETAIL

sehingga laporan yang dihasilkan sesuai dengan data yang sebelumnya telah

110

dimasukkan pada tabel T_LAP_REAL_PO_I_DETAIL oleh user tersebut dengan

menggunakan procedure LAP_REAL_PO_I_OPU_DETAIL. Selain itu,

parameter-parameter lain seperti kode cabang, kode supplier, tanggal, dan lain-lain

juga akan diminta untuk dicantumkan pada header laporan. Keseluruhan parameter

yang diminta adalah sebagai berikut:

1. P Usr

Parameter ini merupakan satu-satunya parameter yang akan digunakan

dalam proses query pada aplikasi sedangkan parameter lain hanya akan

digunakan untuk mengisi header laporan. Melalui parameter ini, user dapat

melihat isi tabel T_LAP_REAL_PO_I_DETAIL yang data-datanya berasal

dari hasil procedure LAP_REAL_PO_I_OPU_DETAIL yang telah

dijalankan user tersebut.

2. P Sbu

Parameter ini merupakan parameter unit perusahaan yang akan diisi pada

header laporan dengan label SBU.

3. P Cab

Parameter ini merupakan parameter cabang perusahaan yang akan diisi

pada header laporan dengan label CABANG.

4. P Wil

Parameter ini merupakan parameter wilayah perusahaan yang akan diisi

pada header laporan dengan label WILAYAH.

111

5. P Tgl

Parameter ini merupakan parameter tanggal yang akan diisi pada header

laporan dengan label TGL.

6. P Supp

Parameter ini merupakan parameter supplier perusahaan yang akan diisi

pada header laporan dengan label SUPPLIER.

7. P Potype

Parameter ini merupakan parameter jenis PO yang akan diisi pada header

laporan dengan label PO TYPE.

8. P Wh

Parameter ini merupakan parameter warehouse yang akan diisi pada

header laporan dengan label WAREHOUSE.

9. P Ret

Parameter ini merupakan parameter retail yang akan diisi pada header

laporan dengan label RETAIL.

112

3.2.4 Spesifikasi Hardware dan Software

Spesifikasi hardware dan software yang dipakai pada DBMS serta aplikasi

Reporting Purchase Order perusahaan ini adalah sebagai berikut:

Spesifikasi

Prosesor Server Quad Core Processor

RAM Server 32GB

Hard Disk Server 1 TB

Operating System Server Red Hat Enterprise Linux x86-64

Database Oracle Database 10g R2

Report Builder Oracle Developer Suite 10 g

Tabel 3.22 Tabel spesifikasi sistem

3.3 Permasalahan yang Dihadapi

Berdasarkan hasil wawancara dan survei yang telah dilakukan, masalah yang

dihadapi PT. Indomarco Prismatama saat ini terletak pada salah satu aplikasi yang

terkait dengan DBMS-nya yakni aplikasi Reporting Purchase Order. Aplikasi yang

berfungsi untuk memonitor purchase order (PO) ini membutuhkan waktu yang relatif

cukup lama, yakni sekitar 1 jam bahkan lebih, untuk menghasilkan sebuah laporan PO.

Lamanya waktu yang dibutuhkan untuk menghasilkan laporan PO berdampak negatif

berupa ketidakefisienan waktu yang terutama sering dialami oleh pihak-pihak manajerial

yang sering kali terpaksa harus memundurkan jadwal rapat mereka, hanya demi

menunggu aplikasi ini menghasilkan laporan PO yang mereka butuhkan untuk rapat, dan

tidak jarang juga mereka terpaksa melaksanakan rapat bulanan tanpa laporan PO karena

aplikasi report ini tidak mengeluarkan laporan PO nya tepat waktu.

113

Dari hasil wawancara, penulis menemukan bahwa masalah performance tetap

terjadi baik pada waktu sibuk perusahaan ketika banyak user yang mengakses sistem

maupun pada saat-saat senggang dimana tidak banyak user yang mengakses sistem

seperti pada pagi hari dimana hanya seorang user saja yang menggunakan aplikasi

tersebut.

Selain itu, masalah performance ini juga tetap dirasakan baik oleh user yang

mengakses dari kantor cabang yang jauh dari kantor pusat maupun user yang

mengaksesnya secara langsung dari kantor pusat. Setelah menganalisis hasil wawancara

tersebut, penulis mengambil beberapa kesimpulan sebagai berikut:

1. Aspek pengaturan pada Oracle Instance, seperti pembagian memory, tidak

terindikasi kuat sebagai faktor utama penyebab masalah. Hal ini dikarenakan

masalah kelambatan tetap terjadi setiap saat tanpa mempedulikan besar tidaknya

load pada database.

2. Aspek networking yang menghubungkan client dengan server, tidak terindikasi

kuat sebagai faktor utama penyebab masalah. Hal ini dikarenakan masalah

kelambatan tetap terjadi baik pada user yang melakukan akses melalui client yang

jauh dari server maupun pada user yang melakukan akses melalui client yang

sangat dekat dengan server yakni di kantor pusat.

Setelah melakukan analisis dari beberapa aspek yang mungkin menjadi penyebab

utama masalah kelambatan, penulis mengambil kesimpulan bahwa faktor utama

penyebab kelambatan pada aplikasi ini terindikasi kuat terletak pada:

1. Data model yang kurang baik terindikasi dari banyaknya redudansi data dan

operasi join yang kompleks.

114

2. PL/SQL code pada procedure pada aplikasi yang sangat tidak efisien terutama

pada algoritmanya yang melakukan operasi delete dan insert setiap kali procedure

dijalankan. Ketidak-efisienan juga terlihat dari banyaknya code yang tidak

dibutuhkan. Hal ini terlihat dengan adanya beberapa penggunaan proses looping

yang tidak perlu.

Dari hasil wawancara lebih lanjut, penulis menemukan bahwa kedua faktor penyebab

masalah kelambatan aplikasi itu muncul dikarenakan database dan aplikasi sering

mengalami perubahan atau penambahan modul, tanpa melalui tahapan analisis dan

perancangan yang mendalam telebih dahulu, untuk memenuhi permintaan user.

3.4 Usulan Solusi Pemecahan Masalah

Berdasarkan permasalahan yang dihadapi PT. Indomarco Prismatama pada aplikasi

Reporting Purchase Order, maka usulan solusi pemecahan atas masalah yang diajukan

adalah dengan melakukan reactive performance tuning untuk response time pada data

model dan PL/SQL code yang digunakan pada aplikasi Reporting Purchase Order.

Dengan melakukan tuning pada komponen-komponen yang berkaitan dengan aplikasi

tersebut, performance dari sisi response time aplikasi Reporting Purchase Order

diharapkan dapat lebih baik sehingga aplikasi tersebut mampu menghasilkan laporannya

dengan lebih cepat.

115

3.5 Perancangan

3.5.1 Restrukturisasi Procedure dengan Penggunaan Materialized View

Berdasarkan hasil analisis pada procedure, dapat dilihat bahwa tabel

T_LAP_REAL_PO_I_DETAIL tidak digunakan secara efisien. Setiap kali ingin

menghasilkan laporan, user harus menjalankan procedure untuk menghapus semua

data sebelumnya dan memasukkan kembali data baru pada tabel ini, baru

kemudian aplikasi Reporting Purchase Order dijalankan untuk melakukan query

pada tabel ini dan tabel penyusun laporan lainnya. Dengan demikian proses yang

terjadi jika disederhanakan terdiri dari delete, insert dan select.

Proses delete-insert yang harus selalu dilakukan setiap aplikasi dijalankan

tentunya memakan waktu dan sangat tidak efisien, maka untuk mengatasinya

penulis akan menghilangkan proses delete dan insert tersebut dengan merancang

sebuah procedure baru. Procedure baru ini hanya akan melakukan proses select

pada sebuah materialized view MV_LAP_REAL_PO_I_DETAIL yang akan

digunakan sebagai pengganti tabel T_LAP_REAL_PO_I_DETAIL. Dengan

menggunakan materialized view yang up to date, user tidak perlu lagi menjalankan

proses delete dan insert pada procedure LAP_REAL_PO_I_OPU_DETAIL. Selain

itu, materialized view ini juga sudah memuat data hasil join beberapa tabel

sehingga penggunaan operasi join yang kompleks tidak perlu dilakukan lagi. Hal

ini sangat kontras sekali jika dibandingkan dengan procedure lama yang

menggunakan view VU_LAP_REAL_PO_ITEM. Pada view tersebut, operasi join

yang kompleks tetap dilakukan karena view harus tetap mengakses tabel asli. View

hanya mengurangi kompleksitas code pada procedure tetapi sama sekali tidak

meningkatkan performance. Penghapusan proses delete dan insert yang tidak

116

efisien serta operasi join yang kompleks dengan menggunakan procedure baru

yang memanfaatkan materialized view MV_LAP_REAL_PO_I_DETAIL

diharapkan dapat meningkatkan response time aplikasi.

Materialized view ini memuat data yang sebagian besar sama dengan data

yang disimpan pada tabel T_LAP_REAL_PO_I_DETAIL. Akan tetapi, pada

materialized view dilakukan pemangkasan beberapa kolom yang tidak digunakan

di dalam procedure LAP_REAL_PO_I_OPU_DETAIL dan penambahan beberapa

kolom baru guna mengurangi proses pengaksesan tabel lain yang berguna dalam

proses validasi parameter. Kolom-kolom yang dihilangkan pada materialized view


1. FTKDIV dan FTKDEP

Kedua kolom di atas dihilangkan karena dalam proses pemasukan data

pada tabel T_LAP_REAL_PO_I_DETAIL, kolom-kolom di atas tidak

dimasukkan nilai sama sekali. Dalam laporan pun, nilai keempat kolom ini

tidak diakses.

2. FTTGUP dan FTUSER

Kolom FTUSER yang awalnya berguna untuk menandai record

T_LAP_REAL_PO_I_DETAIL sebagai record hasil procedure

LAP_REAL_PO_I_OPU_DETAIL oleh user tersebut tentunya tidak lagi

diperlukan pada materialized view. Demikian juga dengan FTTGUP yang

merupakan tanggal dilakukannya proses pemasukan data tersebut.

117

Kolom-kolom yang ditambahkan pada materialized view adalah sebagai berikut:

1. FTFCRS

Kolom ini merupakan kolom yang terdapat pada tabel dd_produk dan

digunakan jika parameter p_warehouse pada procedure

LAP_REAL_PO_I_OPU_DETAIL diisi ‘Y’. Untuk mengurangi operasi

join pada procedure baru, maka kolom ini pun dimasukkan pada

materialized view.

2. FTKRTL

Kolom ini merupakan kolom yang terdapat pada tabel d_region_pr dan

digunakan jika parameter p_retail pada procedure

LAP_REAL_PO_I_OPU_DETAIL diisi ‘Y’. Penambahan kolom ini tidak

menambah tabel yang harus di-join-kan karena tabel d_region_pr sudah

merupakan tabel dasar penyusun T_LAP_REAL_PO_I_DETAIL.

3. FTFTBO

Kolom ini terdapat pada tabel t_status dan berhubungan dengan nilai

parameter p_tag pada procedure LAP_REAL_PO_I_OPU_DETAIL.

Kolom ini sudah terdapat pada view VU_LAP_REAL_PO_ITEM

pembentuk tabel T_LAP_REAL_PO_I_DETAIL.

118

4. PO_TYPE

Kolom ini terdapat pada tabel t_po_type dan berhubungan dengan nilai

parameter p_potype pada procedure LAP_REAL_PO_I_OPU_DETAIL.

Kolom ini juga sudah terdapat pada view VU_LAP_REAL_PO_ITEM

pembentuk tabel T_LAP_REAL_PO_I_DETAIL.

5. FTNSBU

Kolom ini merupakan kolom nama unit yang berasal dari tabel T_UNIT.

Data kolom ini dimasukkan pada materialized view

MV_LAP_REAL_PO_I_DETAIL sehingga pada saat menghasilkan

laporan, materialized view MV_LAP_REAL_PO_I_DETAIL tidak perlu

di-join dengan tabel T_UNIT.

6. FTNCAB

Kolom ini merupakan kolom nama cabang yang berasal dari tabel

T_CABANG. Data kolom ini dimasukkan pada materialized view



di-join dengan tabel T_CABANG.

119

7. FTNSUP

Kolom ini merupakan kolom nama supplier yang berasal dari tabel

T_SUPPLIER. Data kolom ini dimasukkan pada materialized view



di-join dengan tabel T_SUPPLIER.

8. FTKPLU

Kolom ini merupakan kolom kode barang pada unit yang berasal dari

tabel M_PLU_KONV. Data kolom ini dimasukkan pada materialized view



di-join dengan tabel M_PLU_KONV.

9. ID_M_PRODUK, ID_T_DEPT, ID_D_REGION_PR, ID_DD_PRODUK,

ID_MD_ORDER, ID_MD_TSTOCK, ID_MD_GOD, ID_T_PO_TYPE,

ID_T_STATUS, ID_T_UNIT, ID_T_SUPPLIER, ID_T_CABANG,

ID_M_PLU_KONV

Kolom-kolom tersebut merupakan kolom-kolom yang berisi ROWID

pada tabel-tabel penyusun materialized view

MV_LAP_REAL_PO_I_DETAIL sehingga proses refresh fast dapat

dilakukan.

120

Perbandingan struktur tabel pada T_LAP_REAL_PO_I_DETAIL dengan

materialized view MV_LAP_REAL_PO_I_DETAIL adalah sebagai berikut:

T_LAP_REAL_PO_I_DETAIL

PK FTNOPOPK FTKODEPK FTUSER

FTNAMAFTSATBFTKSBUFTKWILFTKCABFTQTYBFTTNILFTQTYRFTNILRFTQTYSFTNILSFTNMDMFTKTAGFTKSUPFTTGPOFTKDIVFTKDEPFTTGUPDISKON_GO

MV_LAP_REAL_PO_I_DETAIL

FTNOPOFTKODEFTNAMAFTSATBFTKSBUFTKWILFTKCABFTQTYBFTTNILFTQTYRFTNILRFTQTYSFTNILSFTNMDMFTKTAGFTKSUPFTTGPODISKON_GOFTFCRSFTKRTLFTFTBOPO_TYPEFTNSBUFTNCABFTNSUPFTKPLUID_M_PRODUKID_D_REGION_PRID_MD_TSTOCKID_MD_ORDERID_DD_PRODUKID_MD_GODID_T_DEPTID_T_STATUSID_T_PO_TYPEID_T_UNITID_T_SUPPLIERID_M_PLU_KONVID_T_CABANG

Gambar 3.5 Perbandingan Tabel T_LAP_REAL_PO_I_DETAIL dan

Materialized View MV_LAP_REAL_PO_I_DETAIL

121

Skema tabel dasar pembentuk materialized vied MV_LAP_REAL_PO_I_DETAIL


Gambar 3.6 Skema Pembentukan Materialized View

MV_LAP_REAL_PO_I_DETAIL

122

Hal yang harus diperhatikan sebelum membuat materialized view

MV_LAP_REAL_PO_I_DETAIL adalah pembuatan materialized view log pada

tabel-tabel dasar penyusun materialized view ini. Materialized view log ini

dibutuhkan agar proses refresh dengan metode fast bisa digunakan pada

materialized view. Materialized view log akan mencatat record yang mengalami

perubahan pada tabel dasar sehingga ketika refresh dijalankan hanya record-

record yang mengalami perubahan yang ikut di-update pada materialized view.

Syarat pembuatan materialized view log pada sebuah tabel adalah tabel tersebut

harus memiliki constraint primary key yang didefinisikan pada tabel tersebut. Oleh

sebab itu, penambahan constraint primary key pada tabel-tabel dasar penyusun

materialized view MV_LAP_REAL_PO_I_DETAIL perlu dilakukan. Selain

penambahan constraint primary key, pengecekan constraint juga perlu dilakukan

pada tabel -tabel tersebut mengingat tabel-tabel tersebut tidak memiliki primary

key sebelumnya. Selain itu, agar proses refresh fast dapat dilakukan, maka pada

materialized view harus disimpan ROWID dari setiap tabel penyusun materialized

view.

Struktur dan isi procedure baru yang menggunakan materialized view

MV_LAP_REAL_PO_I_DETAIL tentu saja berbeda dengan procedure

sebelumnya. Pada procedure yang lama, dilakukan proses insert atau pemasukan

record, dari view VU_LAP_REAL_PO_ITEM dan tabel-tabel lainnya seperti

MD_TSTOCK, MD_GOD dan T_PO_TYPE, sesuai parameter-parameter yang

diberikan pada tabel T_LAP_REAL_PO_I_DETAIL. Pada procedure baru, akan

dibuat sebuah SQL statement untuk mengakses record berdasarkan parameter-

123

parameter tersebut. Pedoman yang digunakan penulis ketika melakukan pembuatan

procedure yang baru adalah procedure yang baru harus memiliki fungsionalitas

dan efektivitas yang sama dengan procedure yang lama. Perbedaan PL/SQL code

antara procedure lama dan procedure baru adalah sebagai berikut:

1. SQL statement pada procedure lama yang pasti dijalankan apapun

parameter yang diberikan adalah sebagai berikut:

Di procedure baru hal ini diganti menjadi:

select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1) and trim(p_cab2) and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2);

select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU,

FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2;

124

2. Jika p_all = ‘Y’ dan p_potype =’A’, maka pada procedure lama, record

yang dimasukkan berasal dari SQL statement berikut:

Sedangkan pada procedure baru, dilakukan proses select berikut:

select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2);


FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2;

125

3. Jika p_all = ‘Y’ dan p_potype tidak bernilai ’A’, maka pada procedure

lama, record yang dimasukkan pada procedure lama berasal dari SQL

statement berikut:


select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) and po_type = p_tipepo;


FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2 and po_type = p_tipepo;

126

4. Jika p_all tidak benilai ‘Y’ dan p_potype = ’A’, maka pada procedure lama,

record yang dimasukkan berasal dari SQL statement berikut:


select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);


FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2 fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);

127

5. Jika p_all tidak benilai ‘Y’ dan p_potype tidak bernilai ’A’, maka pada

procedure lama, record yang dimasukkan berasal dari SQL statement

berikut:


SQL statement pada proses select di materialized view selanjutnya akan

menggunakan SQL statement berdasarkan p_all dan p_potype di atas,

ditambah dengan conditional clause pada WHERE clause untuk proses

validasinya.

select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) and po_type = p_tipepo and fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);


FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2; and po_type = p_tipepo and fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);

128

6. Pada procedure lama, validasi p_tag dilakukan dengan SQL statement

berikut:

Sedangkan pada procedure baru, validasi ini dilakukan dengan

menambahkan conditional clause berikut pada WHERE clause di SQL

statement yakni sebagai berikut:

a. Jika p_tag =’A’, maka tambahkan:

AND FTFTBO != ‘Y’

b. Jika p_tag =’N’, maka tambahkan:

AND FTFTBO = ‘Y’

v_tru:=true; if p_tag='A' then

if cur_rec.ftftbo='Y' then v_tru:=false; end if; elsif p_tag='N' then if cur_rec.ftftbo is null

or cur_rec.ftftbo='N' then v_tru:=false; end if; end if;

129

7. Pada procedure lama, jika p_usr terdapat pada tabel t_tag_lap, maka akan

dilakukan validasi berikut untuk mengecek apakah kode status barang

record yang ingin dimasukkan ke tabel T_LAP_REAL_PO_I_DETAIL

saat itu sama dengan kode status yang dapat dimiliki user tersebut pada

tabel t_tag_lap. Proses validasi yang dilakukan adalah sebagai berikut:

Sedangkan pada procedure yang baru, validasi dilakukan dengan

menambahkan conditional clause berikut pada WHERE clause di SQL

statement berikut:

AND ftktag in(select ftkode from t_tag_lap

where ftuser=p_usr)

if v_tru and v_tag then select count(ftkode) into v_count from t_tag_lap

where ftkode=cur_rec.fdksts and ftuser=p_usr; if v_count=0 then v_tru:=false; end if; end if;

130

8. Pada procedure lama, validasi untuk p_warehouse dan p_retail dilakukan

dengan validasi berikut:

v_warehouse := false; if nvl(p_warehouse,'N') = 'Y' then

open warehouse(cur_rec.fdkode,cur_rec.fdksbu); fetch warehouse into v_temp; if warehouse%found then v_warehouse := true; end if; close warehouse; else v_warehouse := true; end if; v_retail := false; if p_retail = 'Y' then open retail(cur_rec.fdkode,cur_rec.fdksbu,cur_rec.fdkwil); fetch retail into v_temp; if retail%found then v_retail := true; end if; close retail; else v_retail := true; end if;

131

Cursor warehouse dan cursor retail yang digunakan didefinisikan sebagai

berikut:

Sedangkan pada procedure yang baru, validasi ini dilakukan dengan

menambahkan condition clause berikut pada WHERE clause di SQL

statement berikut:

a. Jika p_warehouse=’Y’ maka tambahkan

AND FTFCRS = ‘Y’

b. Jika p_retail =’Y’ maka tambahkan

AND FTKRTL = ‘Y’

Dengan melakukan perubahan-perubahan di atas, maka procedure baru akan

tetap memiliki fungsionalitas dan efektivitas yang sama dengan procedure lama

dalam menghasilkan data.

cursor warehouse(p_plu number,p_opu varchar2)is select 1 from dd_produk where fdkode = p_plu and fdksbu = p_opu and fdfcrs = 'Y'; cursor retail (p_plu1 number,p_opu1 varchar2,p_reg1 varchar2)is select 1 from d_region_pr where fdkode = p_plu1 and fdksbu = p_opu1 and fdkwil = p_reg1 and fdkrtl = 'Y';

132

3.5.2 Normalisasi dan Denormalisai

Normalisasi dan denormalisasi, yang merupakan salah satu teknik pada

data model tuning, dapat dilakukan sebagai salah satu cara untuk meningkatkan

performance. Hasil analisis pada tabel-tabel yang sebelumnya telah dilakukan

menunjukan bahwa memang terdapat banyak redudansi data yang tidak perlu pada

tabel-tabel tersebut. Akan tetapi, melakukan proses normalisasi dan denormalisasi

pada struktur database perusahaan sangat tidak practical. Dikatakan tidak

practical, karena struktur tabel yang dipakai perusahaan ini tidak hanya digunakan

oleh aplikasi Reporting Purchase order tetapi juga dipakai oleh aplikasi penting

perusahaan lainnya sehingga jika proses normalisasi dan denormalisasi

diimplementasikan akan menyebabkan perombakan total juga terhadap sekian

banyak aplikasi penting tersebut. Hal ini tidak sesuai dengan salah satu kriteria

metodologi tuning yang baik menurut Milsap (2003, Chapter 1.2) yaitu practicality

yang berarti metodologi harus dapat dipakai pada keadaan apapun, dalam berbagai

lingkungan.

3.5.3 Pemberian Index

Penggunaan index yang tepat, sesuai dengan yang tertulis pada landasan

teori, secara umum dapat meningkatkan waktu pencarian data dalam suatu tabel.

Pada perancangan ini, data yang akan diberi index adalah kolom yang sering

digunakan dalam operasi where dan join. Index tidak diberikan lagi pada kolom-

kolom primary key karena primary key sendiri sudah merupakan index. Pemberian

index juga akan dilakukan pada materialized view

133

MV_LAP_REAL_PO_I_DETAIL serta tabel-tabel lain yang digunakan pada

procedure baru.

Pengaksesan materialized view pada procedure baru, dengan WHERE

clause yang ditentukan dari parameter-parameter pada saat menjalankan procedure,

akan menggunakan sejumlah kolom yang tidak sedikit. Namun ada beberapa

kolom yang akan selalu digunakan seperti ftksbu, ftkwil, ftkcab, ftksup, fttgpo, dan

ftftbo. Kolom ftftbo nantinya akan dicek berdasarkan parameter p_tag yang

diberikan. Berikut SQL statement yang pasti digunakan:

Selain kolom-kolom di atas, kolom-kolom lain yang akan diakses,

berdasarkan parameter yang ada, pada WHERE clause adalah sebagai berikut:

select FTNOPO, FTKODE, FTNAMA, FTSATB,

FTKSBU, FTKWIL, FTKCAB, FTQTYB,

FTTNIL, FTQTYR, FTNILR, FTQTYS,

FTNILS, FTNMDM, FTKTAG, FTKSUP,

FTTGPO, FTKDIV, FTKDEP, FTKATB,

FTTGUP, FTUSER, FTNCAB, FTNSBU,

FTNSUP, FTKPLU, DISKON_GO

from MV_LAP_REAL_PO_I_DETAIL

where fdksbu between p_ksbu1 and p_ksbu2 and

fdkwil=p_kwil and

fdkcab between p_cab1 and p_cab2 and

fdksup between p_sup1 and p_sup2 and

fdtgpo between p_date1 and trunk p_date2;

AND ftftbo …;

134

1. po_type

Kolom ini diakses jika parameter p_potype diisi ‘B’ atau ‘C’

2. ftkode

Kolom ini diakses jika parameter p_all diisi ‘N’

3. ftfcrs

Kolom ini diakses jika parameter p_warehouse diisi ‘Y’

4. ftkrtl

Kolom ini diakses jika parameter p_retail diisi ‘Y’

5. ftktag

Kolom ini diakses jika parameter p_usr berada pada tabel t_tag_lap

Sehingga jika disimpulkan, kolom-kolom yang digunakan dalam WHERE

clause dan merupakan kolom yang akan diberi index pada materialized view

MV_LAP_REAL_PO_I_DETAIL adalah sebagai berikut:

1. FTKSBU

2. FTKWIL

3. FTKCAB

4. FTKSUP

5. FTTGPO

6. PO_TYPE

135

7. FTKODE

8. FTKTAG

9. FTFCRS

10. FTKRTL

11. FTFTBO

Karena kolom-kolom ini memiliki cardinality yang rendah, maka index yang akan

dibuat pada kolom-kolom ini adalah bitmap index.

3.5.4 Partitioning

Tabel yang berukuran besar dapat dipartisi menjadi bagian-bagian yang

lebih kecil untuk mempercepat pembacaan tabel. Sebuah materialized view seperti

tabel juga dapat dipartisi menjadi bagian-bagian yang lebih kecil berdasarkan field

tertentu. Materialized view MV_LAP_REAL_PO_I_DETAIL yang berukuran

sangat besar dapat mengakibatkan proses pengaksesan menjadi lebih lambat. Oleh

sebab itu, perlu dilakukan partitioning pada materialized view tersebut. Dari hasil

wawancara, laporan yang biasanya dihasilkan merupakan laporan bulanan. Maka

dari itu, partisi berdasarkan bulan pada materialized view

MV_LAP_REAL_PO_I_DETAIL dianggap yang paling sesuai oleh penulis.

indomaret2

Documents

Transcript of indomaret2