indomaret2
-
Upload
wafi-dhiyaulhasan-ali -
Category
Documents
-
view
102 -
download
0
Transcript of 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
Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut:
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
Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut:
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
Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut:
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
Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut:
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
Jenis Ukuran
FDKODE Kode produk NUMBER 8
FDKSBU Kode unit CHAR 1 BYTE
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.
Field Keterangan Tipe Data
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.
Field Keterangan Tipe Data
Jenis Ukuran
FDNOUO Nomor UO VARCHAR2 9 BYTE
FDKODE Kode produk NUMBER 8
FDISIP Satuan isi NUMBER 6
FDSATB Satuan barang VARCHAR2 3 BYTE
FDTGUO Tanggal UO DATE
FDKSBU Kode unit CHAR 1 BYTE
FDKWIL Kode wilayah VARCHAR2 3 BYTE
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
Field Keterangan Tipe Data
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
Field Keterangan Tipe Data
Jenis Ukuran
FDNOPO Nomor PO VARCHAR2 9 BYTE
FDKODE Kode produk NUMBER 8
FDKSBU Kode unit CHAR 1 BYTE
FDKWIL Kode wilayah VARCHAR2 3 BYTE
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
Field Keterangan Tipe Data
Jenis Ukuran
FDNOPO Nomor PO VARCHAR2 9 BYTE
FDKODE Kode produk NUMBER 8
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
Field Keterangan Tipe Data
Jenis Ukuran
FTNOPO Nomor PO VARCHAR2 9 BYTE
FTKODE Kode produk NUMBER 8
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.
Field Keterangan Tipe Data
Jenis Ukuran
FTKODE Kode status barang VARCHAR2 2 BYTE
FTUSER Kode user VARCHAR2 15 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
Field Keterangan Tipe Data
Jenis Ukuran
FTKODE Kode produk NUMBER 8
FTUSER Kode user VARCHAR2 15 BYTE
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_LAP_REAL_PO_I_DETAIL 1..*
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_LAP_REAL_PO_I_DETAIL 1..*
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_LAP_REAL_PO_I_DETAIL 1..*
T_DIVISI 1..1 Memiliki
departemen
T_DEPT 1..*
1..1 Memiliki
master
produk
M_PRODUK 1..*
1..1 Memiliki
realisasi
order
T_LAP_REAL_PO_I_DETAIL 1..*
T_DEPT 1..1 Memiliki
master
produk
M_PRODUK 1..*
1..1 Memiliki
realisasi
order
T_LAP_REAL_PO_I_DETAIL 1..*
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
T_LAP_REAL_PO_I_DETAIL 1..*
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
T_LAP_REAL_PO_I_DETAIL 1..*
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
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 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
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, p_date2, dan p_potype. Cursor ini
menghasilkan data tanpa memperhatikan user tetapi berdasarkan jenis PO
tertentu.
4. Cursor cur4
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, 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
adalah sebagai berikut:
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
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_CABANG.
119
7. FTNSUP
Kolom ini merupakan kolom nama supplier yang berasal dari tabel
T_SUPPLIER. 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_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
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 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
adalah sebagai berikut:
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);
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;
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:
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) and po_type = p_tipepo;
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 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:
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) fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);
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 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:
Sedangkan pada procedure baru, dilakukan proses select 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);
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 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.