bab 3 analisis dan perancangan 3.1 analisisthesis.binus.ac.id/asli/bab3/2011-2-00303-if bab...

53

BAB 3

ANALISIS DAN PERANCANGAN

3.1 Analisis

3.1.1 Sejarah Perusahaan

PT. Langgeng Pranamas Sentosa adalah perusahaan yang

bergerak di bidang jasa pengangkutan pengiriman motor, mobil,

sparepart motor dan mobil, pengiriman barang - barang dengan

menggunakan kontainer, pengiriman barang secara LCL (Less Than

Container Load – Pengiriman barang yang kurang dari standar kargo

kontainer), Penerimaan barang dari seluruh daerah Indonesia ke

Jabodetabek. PT. Langgeng Pranamas Sentosa diprakarrsai oleh Bapak

Mochtar Pitojo, Ibu Oei Lee Hoa dan Koko Hermawan, dengan presentase

kepemilikan saham :

1. Bapak Mochtar Pitojo - 68%

2. Ibu Oei Lee Hoa - 30%

3. Koko Hermawan - 2%

PT. Langgeng Pranamas Sentosa didirikan pada tanggal 3 Juni 1991

dengan Akta Nomor 10 yang dibuat oleh Notaris Darsono Purmomosidi

SH, dan dilakukan perubahan dengan Akta Nomor 51 tanggal 23 Agustus

2000 dibuat oleh Notaris yang sama dan terakhir dilakukan perubahan

dengan Akta Nomor 5 pada tanggal 8 Maret 2004 yang dibuat oleh Notaris

Mutiara Hartanto, SH.

54

Dengan Prinsip yang dipegang oleh PT. Langgeng Pranamas

Sentosa yaitu “Pengiriman yang tepat waktu dengan kondisi baik yang

disertai dengan laporan pengiriman yang cepat dan akurat”, PT.Langgeng

mendapat kepercayaan dari berbagai klien untuk mengirimkan barang -

barang ke berbagai daerah. PT. Langgeng juga merupakan jasa pengiriman

yang diperlengkapi dengan sumber daya yang memadai, karena perusahaan

dalam menjalankan bisnis pengiriman barang, perusahaan juga bermitra

dengan 12 mitra pelayaran untuk mengirimkan barang – barang keluar

daerah.

Gedung kantor dan garasi PT. Langgeng Pranamas Sentosa,

berlokasi di Jl. Serdang Baru Raya 12 Kemayoran, Jakarta Pusat. Namun

pada tanggal 11 Januari 2010 kemarin, PT. Langgeng Pranamas Sentosa

baru saja meresmikan pendirian kantor dan garasi baru di Jl. Babek ABRI 3

C, Cakung, Jakarta Utara. Adapun garasi lama di Serdang Baru Raya

masih beroperasi untuk menunjang pergerakan armada perusahaan. Dengan

lokasi baru ini, PT. Langgeng lebih mudah me-monitoring pergerakan

armada yang berjalan, dan lebih memungkinkan perusahaan untuk

melakukan proses striping dan stuffing (bongkar muat) tanpa perlu ke

pelabuhan sehingga mempercepat proses pengiriman.

55

3.1.2 Visi dan Misi

Visi : Menjadi perusahaan pengiriman jasa angkutan yang berorientasi

kepada kepuasan klien dan dikenal di seluruh nusantara.

Misi :

a. Menjadi perusahaan pengiriman jasa pengangkutan yang berorientasi

kepada kebutuhan klien, dan terus melakukan peningkatan - peningkatan

diberbagai bidang untuk kelancaran pelayanan pengiriman.

b. Memberi jasa pelayanan yang cepat, tepat, dan terpecaya.

c. Bermitra dengan berbagai perusahaan pelayaran guna untuk menjalankan

pengiriman, baik via darat dan laut. Sehingga bisa mengirimkan barang

keluar daerah.

d. Menjalin kerjasama yang erat dengan pelanggan dan lembaga - lembaga

yang terkait dalam menjalankan bisnis perusahaan.

e. Memiliki prinsip “Pengiriman yang tepat waktu dengan kondisi baik yang

disertai dengan laporan pengiriman yang cepat dan akurat”.

56

3.1.3 Struktur Organisasi

Berikut ini adalah struktur organisasi dari PT. Langgeng Pranamas

Sentosa:

Gambar 3.1 Struktur Organisasi PT. Langgeng Pranamas Sentosa

3.1.4 Pembagian Tugas dan Tanggung Jawab

Adapun tanggung jawab dan wewenang dari masing – masing

departemen pada struktur organisasi PT. Langgeng Pranamas Sentosa

adalah sebagai berikut :

1. Direktur

Tanggung jawab Direktur :

a. Menentukan kebijakan makro perusahaan yang perlu diambil.

b. Menentukan arah dan tujuan bisnis perusahaan.

c. Memajukan perusahaan dalam waktu sesingkatnya.

d. Menetapkan visi dan misi perusahaan.

e. Menetapkan dan mengarahkan strategi umum perusahaan dan

disesuaikan dengan kebutuhan serta aktivitas perusahaan.

57

Wewenang Direktur :

a. Mewakili perseroan di dalam dan di luar pengadilan tentang segala

hal dan dalam segala tindakan, baik yang mengenai kepengurusan

maupun kepemilikan.

b. Menetapkan keputusan perjanjian kerjasama dengan pihak lain.

2. General Manager

Tanggung jawab General Manager :

a. Merumuskan kebijakan mikro perusahaan dari kebijakan makro

yang dikeluarkan oleh direktur.

b. Memastikan semua divisi bisa menjalankan strategi yang telah

ditetapkan oleh perusahaan.

c. Mengadakan evaluasi secara berkala untuk kinerja perusahaan dan

mengambil langkah yang diperlukan untuk meningkatkannya.

d. Bertanggung jawab langsung kepada Direktur.

Wewenang General Manager :

a. Memilih dan mengangkat kepala masing-masing divisi di

perusahaan yang kompeten.

b. Mengevaluasi kinerja kepala masing-masing divisi.

c. Mewakili direktur untuk mengambil keputusan saat direktur sedang

tidak berada di tempat.

3. Finance

Tanggung jawab Finance :

a. Menentukan kebijakan keuangan perusahaan yang perlu diambil.

b. Menentukan kebijakan keuangan yang diutamakan.

58

c. Mengatur posisi kas dan bank perusahaan.

d. Mengatur hutang dan piutang perusahaan.

Wewenang Finance :

Menentukan dan mengeluarkan budget untuk masing-masing divisi.

3.1 Bagian Kas

Tanggung jawab bagian kas :

a. Menentukan budget kas selama 1 minggu.

b. Memastikan jumlah uang kas dalam brankas sama dengan laporan

Accounting.

c. Memastikan jumlah uang yang diterima dari customer secara cash

sama dengan jumlah pada invoice.

Wewenang bagian kas :

a. Membagi uang yang didapatkan dari budget sesuai dengan

kebutuhan.

b. Memilih biaya tertentu dari divisi tertentu yang layak

diprioritaskan pada saat dana terbatas.

c. Menerima uang cash dari customer.

3.2 Bagian Administrasi

Tanggung jawab bagian administrasi :

a. Membuat Berita Acara Penerimaan Barang (BAPB).

b. Membuat laporan pengiriman barang secara detail.

c. Mengirimkan email jadwal keberangkatan kapal secara berkala.

d. Membuat kuitansi untuk customer.

59

e. Merapikan dokumen-dokumen di atas untuk keperluan

pengarsipan.

f. Memberikan faktur untuk dicatat oleh bagian accounting secara

berkala.

g. Menerima telepon untuk penerimaan order dan saran dari

customer.

Wewenang bagian administrasi :

Menerima order satuan dengan harga yang sudah ditentukan oleh

perusahaan.

3.3 Bagian Accounting

Tanggung jawab bagian accounting :

a. Melakukan pencatatan pembukuan secara tepat dan detail.

b. Membuat laporan mingguan untuk bagian finance agar bisa

dijadikan sebagai bahan pengambilan keputusan.

Wewenang bagian accounting :

a. Mengadakan cash opname pada bagian kas untuk mencocokkan

hasil laporan dan kenyataan.

b. Mengadakan stock opname pada bagian general affair

4. Operasional

Tanggung jawab Operasional :

a. Menentukan kebijakan operasional perusahaan.

b. Memastikan operasional perusahaan mampu mengimbangi laju

penjualan perusahaan.

c. Mengatur jadwal operasional agar efektif dan efisien.

60

d. Mengatasi berbagai kendala operasional yang mungkin terjadi di

lapangan.

Wewenang Operasional :

a. Mengajukan budget untuk kegiatan operasional ke bagian finance.

b. Memilih dan mengangkat kepala - kepala sub divisi.

4.1 Bagian Pengurus Pabrik

Tanggung jawab bagian pengurus pabrik :

a. Mendatangi pabrik untuk pengambilan Delivery Order sepeda

motor.

b. Berusaha untuk mendapatkan penambahan Delivery Order.

c. Koordinasi dengan bagian pengurus pelabuhan dan bagian

pengurus kendaraan agar pengambilan Delivery Order tidak

mengalami hambatan.

d. Berusaha menghabiskan setiap Delivery Order yang keluar dalam

waktu sesingkatnya.

Wewenang bagian pengurus pabrik :

Mengambil Delivery Order dari pabrik.

4.2 Bagian Pengurus Pelabuhan

Tanggung jawab bagian pengurus pelabuhan :

a. Memastikan jadwal closing kapal dan memberitahukannya kepada

staff administrasi.

b. Berkoordinasi dengan bagian pengurus pabrik dan bagian

pengurus kendaraan agar delivery order yang dikeluarkan pabrik

bisa masuk kapal dengan cepat.

61

c. Memastikan segala perlengkapan sudah baik saat proses

pengiriman.

Wewenang bagian pengurus pelabuhan :

Memerintahkan kepada tukang ikat untuk proses pengikatan

barang yang akan dikirim.

4.3 Bagian Pengurus Kendaraan

Tanggung jawab bagian pengurus kendaraan :

a. Memastikan ada supir yang mengambil Delivery Order dari

pabrik.

b. Memastikan ada supir yang mengantarkan Delivery Order ke

pelabuhan.

c. Memastikan ada container yang kosong untuk pemuatan Delivery

Order di gudang perusahaan.

Wewenang bagian pengurus kendaraan :

Memberi perintah kepada seluruh supir untuk mengambil Delivery

Order dari pabrik.

4.4 Bagian Maintenance Kendaraan

Tanggung jawab bagian maintenance kendaraan :

a. Memastikan seluruh kendaraan dapat beroperasi dengan baik.

b. Memeriksa setiap kendaraan secara berkala untuk mencegah

kemungkinan terjadinya kerusakan yang besar.

c. Memperbaiki kendaraan yang rusak.

Wewenang bagian maintenance kendaraan :

a. Menentukan standar pemeriksaan bagi kendaraan.

62

b. Menentukan kualitas barang yang dibeli bagi perusahaan.

5. General Affair

Tanggung jawab General Affair :

a. Membayar gaji karyawan tepat pada waktunya.

b. Mengurus segala permasalahan karyawan.

c. Memastikan semua komputer dan jaringan dapat berfungsi dengan

baik.

d. Membandingkan harga dan kualitas barang dari para supplier.

Wewenang General Affair :

a. Menentukan besarnya gaji para karyawan.

b. Menentukan kebijakan mutasi dan kenaikan jabatan para

karyawan.

c. Menerima dan memberhentikan karyawan.

d. Menentukan pengambilan barang dari para supplier.

e. Mengajukan budget untuk maintenance komputer dan jaringan.

3.1.5 Prosedur yang Sedang Berjalan

Sistem Inventory yang sedang berjalan di PT. Langgeng Pranamas

Sentosa saat ini mencakup pengaturan persediaan barang di gudang dan

pengambilan barang dari gudang. Semua prosedur ini dilakukan secara

manual dengan melakukan pencatatan pada buku gudang. Berikut ini

merupakan penjelasan prosedur yang sedang berjalan di PT. Langgeng

Pranamas Sentosa:

63

3.1.5.1 Prosedur Persediaan

Pada tahap ini akan dijelaskan bagaimana prosedur yang

sedang berjalan untuk pengaturan persediaan barang. Sistem

yang ada sekarang ini masih dilakukan secara manual, dimana

petugas bagian gudang harus mencatat barang yang keluar

masuk gudang dan mencocokan stok barang yang ada pada buku

gudang dengan stok barang yang dimiliki perusahaan setiap

harinya.

Prosedur yang berjalan dimulai dari bagian gudang

melakukan pemeriksaan stok barang. Jika stok barang masih

mencukupi maka tidak ada tindakan lebih lanjut. Apabila

terdapat stok barang yang mencapai batas minimum, maka

bagian gudang akan membuat list barang yang sudah mencapai

stok minimum yang akan diserahkan kepada General Affair.

General Affair memeriksa list barang minimum yang di buat

bagian gudang, kemudian General Affair membuat purchase

order untuk supplier. Setelah supplier menerima purchase order

, maka supplier menyiapkan faktur barang yang akan dikirim dan

kwitansi barang, lalu mengirimkan barang pesanan perusahaan.

Barang yang sudah diterima oleh bagian gudang diperiksa

apakah sudah sesuai dengan faktur pengiriman. Prosedur

berakhir dengan peng-update-an stok barang oleh bagian

gudang.

64

Gambar 3.2 Flowchart Prosedur Persediaan

65

3.1.5.2 Prosedur Pengambilan Barang

Pada tahap ini akan dijelaskan bagaimana prosedur

pengambilan barang yang sedang berjalan. Prosedur dimulai

ketika ada permintaan barang oleh karyawan PT. Langgeng

Pranamas Sentosa, setiap karyawan yang ingin melakukan

pengambilan barang harus mengisi faktur pengambilan barang

terlebih dahulu. Faktur tersebut diberikan ke bagian gudang,

kemudian bagian gudang akan melakukan pengecekan stok

barang yang diminta. Apabila stok mencukupi, bagian gudang

membuat salinan faktur permintaan barang untuk diserahkan ke

General Affair untuk di-accept dan mengembalikan ke bagian

gudang sebagai bukti izin pengambilan barang dan karyawan

melakukan pengambilan barang dari gudang dan bagian gudang

meng-update stok barang gudang. Jika stok yang dimiliki tidak

mencukupi maka akan dilakukan pemesanan barang seperti yang

terjadi pada prosedur persediaan.

66

Gambar 3.3 Flowchart Prosedur Pengambilan Barang

67

3.1.5.3 Prosedur Retur Barang

Pada tahap ini akan dijelaskan bagaimana prosedur retur

barang yang dilakukan PT. Langgeng Pranamas Sentosa. Saat

bagian gudang melakukan pengecekan stok barang, apabila

terdapat barang yang rusak atau cacat, maka bagian gudang akan

melapor kepada General Affair , kalau tidak ada maka tidak ada

tindakan lebih lanjut. General Affair akan memeriksa status

barang yang cacat, apakah bisa di retur atau tidak. Bila tidak bisa

diretur maka tidak ada tindakan labih lanjut dan bila status

barang bisa diretur, maka dibuat faktur retur barang untuk

diserahkan kepada supplier. Bagian gudang menyiapkan barang

yang akan diretur berdasarkan data yang ada pada faktur, lalu

melakukan peng-update-an stok barang dan supplier akan

mengurangi piutang perusahaan setelah menerima barang dan

faktur retur barang.

68

Gambar 3.4 Flowchart Prosedur Retur Barang

69

3.1.6 Data Flow Diagram (DFD)

Berikut ini merupakan gambaran Data Flow Diagram PT. Langgeng

Pranamas Sentosa.

Gambar 3.5 Diagram Konteks

70

Gambar 3.6 DFD Level 0

71

3.1.7 Analisis Kebutuhan Pengguna

3.1.7.1 Kebutuhan Informasi

1. Informasi mengenai supplier

Dibutuhkan informasi yang memuat data mengenai

supplier yang bekerja sama dengan PT. Langgeng Pranamas

Sentosa. Informasi ini mencakup :

a. Nama PIC Perusahaan Supplier.

b. Alamat Supplier.

c. Telepon Kantor Supplier.

d. HP PIC Supplier.

e. Jenis Usaha Supplier.

2. Informasi mengenai karyawan

Dibutuhkan informasi yang memuat data mengenai

karyawan yang bekerja di PT. Langgeng Pranamas Sentosa.

3. Informasi mengenai persediaan barang

Dibutuhkan informasi mengenai persediaan barang di

gudang atau stok barang yang ada dan barang yang keluar-

masuk dari gudang. Detail informasi persediaan mencakup :

a) Stok Awal Persedian Barang per jenis barang.

b) Penambahan per hari, per minggu, per bulan untuk tiap

jenis barang.

c) Pengambilan per hari, per minggu, per bulan untuk tiap

jenis barang.

72

d) Stok akhir per hari, per minggu, per bulan untuk tiap jenis

barang.

e) Siapa yang ACC untuk pengambilan dan pembelian

barang tersebut.

f) Nama karyawan yang mengambil barang tersebut dan

untuk keperluan apa.

g) Barang tersebut dibeli dari supplier mana.

h) Berapa harga pembelian untuk barang tersebut.

i) Informasi mengenai barang retur.

j) Pemesanan barang.

k) Penerimaan barang.

l) Berapa lama jatuh tempo untuk pembelian barang tersebut.

m) Laporan hutang yang disusun per supplier dan per periode

( misal : per hari, per minggu dan per bulan ).

n) Laporan reminder jatuh tempo per supplier berikut jumlah

hutang.

3.1.7.2 Kebutuhan Aplikasi

1. Keamanan data

Keamanan data data ini dibutuhkan untuk menghindari

kehilangan data dan kemungkinan tindakan penyalahgunaan data

dari berbagai pihak yang tidak diinginkan. Oleh karena itu,

diperlukan adanya kewenangan dalam mengakses data yang ada.

73

2. Kebutuhan Integrasi

Suatu organisasi atau perusahaan membutuhkan suatu

aplikasi yang memiliki basis data yang terintegrasi dengan suatu

sistem. Sistem ini nantinya harus dapat memenuhi kebutuhan

data, yang sebelumnya belum terkoordinasi menjadi suatu

informasi yang memang dibutuhkan oleh perusahaan tersebut.

3. Kebutuhan Kecepatan Akses Data

Perusahan membutuhkan informasi data yang cepat,

tepat, akurat dan up to date. Dengan informasi yang cepat, tepat,

akurat, dan up to date maka proses bisnis akan berjalan lebih

lancar dan tidak terganggu karena dengan dukungan aplikasi,

memungkinkan pengambilan keputusan yang baik.

4. Kebutuhan Transaksi

Dengan adanya aplikasi sistem basisdata yang akan

diimplementasikan ini, diharapkan dapat membantu di dalam

mengorganisir data-data yang berhubungan dengan transaksi

pengambilan dan pemasukan barang yang terjadi di perusahaan.

5. Laporan Manajemen

Dengan adanya aplikasi sistem basisdata yang akan

diimplementasikan ini, diharapkan dapat membantu dalam

pembuatan laporan manajemen dengan data-data yang ada di

dalam basisdata.

74

3.1.8 Permasalahan yang Dihadapi

Permasalahan - permasalahan yang dihadapi PT. Langgeng

Pranamas Sentosa saat ini, yaitu :

1. Sistem berjalan secara manual dan proses bisnis padat sehingga

sering terjadi kesalahan dalam pengaturan inventory. Kesalahan

banyak terjadi dalam pencatatan data stok barang.

2. General Affair menangani banyak aspek bisnis perusahaan

sehingga dibutuhkan waktu untuk menyelesaikan pekerjaan yang

dilakukan secara manual.

3. Kesulitan dalam menyajikan laporan persediaan barang pada saat

dibutuhkan karena sistem belum terkomputerisasi sehingga apabila

dibuat secara manual akan membutuhkan banyak waktu.

3.1.9 Usulan Pemecahan Masalah

Gambaran secara umum usulan pemecahan masalah yang diajukan

adalah dengan merancang basisdata yang sesuai dengan proses bisnis

perusahaan. Selain perancangan basis data, pemecahan masalah

selanjutnya yang diajukan adalah merancang program aplikasi yang

menjadi media interaksi antara pengguna dengan basis data. Program

aplikasi yang dirancang akan didukung dengan keamanan dengan

pemberian hak akses untuk user dan pembuatan laporan-laporan

perusahaan, agar dapat digunakan dengan efektif dan efisien oleh

pengguna dalam mendukung proses bisnis perusahaan yang sedang

75

berjalan. Berikut ini adalah beberapa usulan pemecahan masalah untuk

beberapa permasalahan yang dihadapi :

1. Untuk mengatasi kesalahan pencatatan barang, usulan pemecahan

masalah yang diajukan adalah pembuatan sistem basisdata yang

terintegrasi dengan baik. Dengan adanya sistem basis data maka

proses manajemen inventory menjadi lebih mudah karena stok

barang dalam basisdata akan berkurang ataupun bertambah secara

otomatis saat ada pengambilan atau penerimaan barang.

2. Untuk mengatasi masalah yang dihadapi oleh General Affair yang

menangani banyak aspek, usulan pemecahan maslaah yang

diajukan adalah dengan membuat aplikasi desktop yang berinteraksi

dengan basisdata, sehinngga pengawasan dan manajemen stok

barang menjadi lebih mudah. Selain itu pembuatan laporan juga

menjadi lebih mudah karena pada aplikasi tersedia fitur untuk

laporan.

3. Untuk mengatasi masalah kesulitan penyajian laporan persediaan

barang, usulan pemecahan masalah yang diajukan adalah membuat

aplikasi yang dapat mencetak laporan dari sistem basisdata yang

akan dibuat.

76

3.2 Perancangan

Metodologi perancangan basisdata dibagi ke dalam tiga tahapan utama,

yaitu :

1. Perancangan basisdata konseptual

2. Perancangan basisdata logikal

3. Perancangan basisdata fisikal

3.2.1 Perancangan Basisdata Konseptual

Perancangan basisdata konseptual merupakan proses

pembentukan model dari informasi yang digunakan dalam perusahaan,

independen terhadap semua pertimbangan fisik. Langkah-langkah

perancangan basisdata konseptual :

1. Mengidentifikasi tipe entitas (entity types).

2. Mengidentifikasi tipe relasi (relationship types).

3. Mengidentifikasi tipe dan menghubungkan atribut-atribut dengan tipe

entitas dan tipe relasi.

4. Mengidentifikasi domain atribut.

5. Mengidentifikasi atribut candidate key dan primary key.

6. Mempertimbangkan konsep pemodelan enhanced (optional).

7. Memeriksa model terhadap redundansi.

8. Memvalidasi model konseptual terhadap transaksi pengguna.

9. Meninjau kembali model data konseptual dengan pengguna.

77

3.2.1.1 Mengidentifikasi Tipe Entitas (Entity Types)

Tahapan ini bertujuan untuk mengidentifikasi tipe-tipe entitas

yang utama yang dibutuhkan.

Tabel 3.1 Identifikasi Tipe Entitas

Nama Entitas Deskripsi Alias Kejadian

Employee Merupakan entitas

yang memberikan

informasi tentang

karyawan

Karyawan Pegawai yang

bekerja di

perusahaan.

Item Merupakan entitas

yang memberikan

informasi tentang data

barang

Barang Setiap barang

yang dimiliki dan

dibeli oleh

perusahaan.

Supplier Merupakan entitas

yang memberikan

informasi tentang

pemasok.

Pemasok Pemasok yang

melayani

pembelian barang

dari perusahaan.

OutItem Merupakan entitas

yang memberikan

informasi tentang

barang yang diambil

dari gudang

BarangKeluar Barang apa saja

yang diambil

oleh karyawan

dari gudang.

InItem Merupakan entitas

yang memberikan

informasi tentang

barang yang diterima

oleh karyawan.

BarangMasuk Barang apa saja

yang diantarkan

oleh pemasok

dan diterima oleh

karyawan.

78

PurchaseOrder Merupakan entitas

yang memberikan

informasi tentang

pembelian barang

(purchase order)

Pembelian Perusahaan

memesan barang

ke pemasok.

Hutang Merupakan entitas

yang berisi informasi

pembayaran dari

pembelian barang

perusahaan

Hutang Hutang

perusahaan ke

pemasok atas

pembelian barang

yang sudah

dilakukan.

ReturBarang Merupakan entitas

yang berisi informasi

mengenai

pengembalian barang

yang sudah dibeli ke

pemasok

ReturBarang Pengembalian

barang yang

dibeli jika ada

barang yang

cacat atau rusak.

3.2.1.2 Mengidentifikasi Tipe Relasi (Relationship Types)

Tahapan ini bertujuan untuk mengidentifikasi hubungan-

hubungan yang penting yang terdapat di antara tipe-tipe entitas

yang sudah diidentifikasikan.

Tabel 3.2 Identifikasi Tipe Relationship

Nama

Entitas

Mutiplicity Relationship Nama

Entitas

Multiplicity

Employee 1…1 Melakukan_Pengambilan OutItem 1…*

Employee 1…1 Melakukan_Penerimaan InItem 1…*

79

Employee 1…1 Melakukan_Pengembalian ReturBara

ng

0…*

Employee 1…1 Melakukan_Pemesanan Purchase

Order

1…*

Supplier 1…1 Mendapatkan_Pemesanan Purchase

Order

1…*

Supplier 1…1 Mendapatkan_Pengembalia

n

ReturBara

ng

0…*

Supplier 1…1 Mengirim InItem 1…*

InItem 1…* Menambah Item 1…*

OutItem 1…* Mengurangi_Jumlah Item 1…*

ReturBara

ng

1…* Mengurangi_Jumlah Item 1…*

Purchase

Order

1…1 Menambah Hutang 1…1

Purchase

Order

1…* Memuat Item 1…*

Purchase

Order

1…1 Menyebabkan InItem 1…1

80

Gambar 3.7 Entity Relationship Diagram dengan Relationship

3.2.1.3 Mengidentifikasi Tipe dan Menghubungkan Atribut-atribut

Dengan Tipe Entitas dan Tipe Relasi

Tahapan ini bertujuan untuk mengidentifikasi dan

menggabungkan atribut yang digunakan dalam suatu entitas, serta

tipe data masing-masing atribut yang digunakan.

1. Tabel Employee

Atribut Deskripsi Panjang

dan Tipe

Data

Nulls Multi-

valued

EmID Kode dari

karyawan

Char(10) No No

NamaKaryawan Nama dari

karyawan

Varchar(50) No No

AlamatKaryawan Alamat karyawan Varchar(60) No No

TelpKaryawan No telp karyawan Varchar(15) Yes No

81

EmailKaryawan Email karyawan Varchar(30) Yes No

Jabatan Jabatan karyawan Varchar(30) No No

Username Nama user Varchar(50) Yes No

2. Tabel Item

Atribut Deskripsi Panjang dan

Tipe Data

Nulls Multi-

valued

BID Kode dari barang Char(10) No No

NamaBarang Nama barang Varchar(30) No No

Stock Jumlah barang Int No No

Unit Satuan barang Varchar(10) No No

MinimumStock Batas minimal

barang

Int No No

JenisBarang Jenis barang Varchar(20) No No

3. Tabel Supplier


Tipe Data

Nulls Multi-

valued

SupID Kode supplier Char(10) No No

NamaSupplier Nama supplier Varchar(50) No No

AlamatSupplier Alamat supplier Varchar(60) No No

TelpSupplier Nomor telepon

supplier

Varchar(15) No No

HPSupplier Nomor HP

supplier

Varchar(15) Yes No

JenisSupplier Jenis usaha

supplier

Varchar(30) No No

82

4. Tabel OutItem

Atribut Deskripsi Panjang

dan Tipe

Data

Nulls Multi-

valued

OutID Kode

pengambilan

Int No No

TanggalOut Tanggal

pengambilan

Datetime No No

EmID Kode Karyawan

yang mengambil

Char(10) No No

NamaKaryawan Nama Karyawan Varchar(50) No No

NamaAccepter Nama karyawan

yang memberi

izin

Varchar(50) No No

BID Kode barang Char(10) No No


Qty Jumlah barang Int No No


StokAwal Jumlah barang

sebelum diambil

Int No No

StokAkhir Jumlah barang

setelah diambil

Int No No

AlasanPengambilan Alasan

pengambilan

Varchar(100) No No

5. Tabel InItem


Tipe Data

Nulls Multi-

valued

InID Kode penerimaan

barang

Int No No

83

TanggalIn Tanggal penerimaan

barang

Datetime No No

POID Kode purchase order Char(10) No No

EmID Kode Karyawan Char(10) No No

NamaPenerima Nama penerima Varchar(50) No No

SupID Kode Supplier Char(10) No No

NamaSupplier Nama Supplier Varchar(50) No No

BID Kode Barang Char(10) No No

NamaBarang Nama Barang Varchar(30) No No



StokAwal Jumlah barang

sebelum pengiriman

Int No No

StokAkhir Jumlah barang

setelah pengiriman

Int No No

6. Tabel PurchaseOrder


Tipe Data

Nulls Multi-

valued

POID Kode purchase

order

Char(10) No No

TanggalPO Tanggal purchase

order

Date No No

EmID Kode karyawan Char(10) No No

NamaKaryawan Nama karyawan Varchar(50) No No






84


Harga Harga barang per

satuan

Decimal

(20,2)

No No

SubTotal Harga barang

dikali jumlah

barang

Decimal

(20,2)

No No

Disc Potongan harga Decimal

(20,2)

No No

GrandTotal Total pembeliaan Decimal

(20,2)

No No

7. Tabel Hutang


Tipe Data

Nulls Multi-

valued

HID Kode hutang Int No No

POID Kode purchase

order

Char(10) No No

JatuhTempo Tanggal jatuh

tempo

pembayaran

Date No No

JumlahPembayaran Jumlah yang

harus dibayar

Decimal

(20,2)

No No

Status Status Hutang Char(2) No No

8. Tabel ReturBarang


Tipe Data

Nulls Multi-

valued

ReID Kode retur barang Int No No

85

TanggalRetur Tanggal retur

barang

Datetime No No



EmID Kode karyawan Char(10) No No

NamaKaryawan Nama karyawan Varchar(50) No No





AlasanRetur Alasan retur

barang

Varchar(100) No No

3.2.1.4 Mengidentifikasi Domain Atribut

Tahapan ini bertujuan untuk menentukan domain dari

atribut yang terdapat pada model data konseptual.

1. Tabel Employee

Atribut Domain Value

EmID Range Value a-z, A-Z, 0-9

Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

NamaKaryawan Range Value a-z, A-Z

AlamatKaryawan Range Value a-z, A-Z, 0-9, ‘.’, ‘,’

TelpKaryawan Range Value 0-9

EmailKaryawan Range Value a-z, A-Z, 0-9, ‘.’, ‘,’, ‘@’, ’_’

86

Jabatan Range Value a-z, A-Z

Username Range Value a-z, A-Z

2. Tabel Item


BID Range Value a-z, A-Z, 0-9

Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

NamaBarang Range Value a-z, A-Z

Stock Range Value 0-9

Unit Range Value a-z, A-Z, 0-9

MinimumStock Range Value 0-9

JenisBarang Range Value a-z, A-Z

3. Tabel Supplier


SupID Range Value a-z, A-Z, 0-9

Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

NamaSupplier Range Value a-z, A-Z

AlamatSupplier Range Value a-z, A-Z, 0-9, ‘.’, ‘,’

TelpSupplier Range Value 0-9

HPSupplier Range Value 0-9

JenisSupplier Range Value a-z, A-Z

87

4. Tabel OutItem


OutID autonumber

TanggalOut Range Value 0-9, ‘/’, “:”

Format dd/mm/yy hh:mm:ss


Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]


NamaAccepter Range Value a-z, A-Z


Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]


Qty Range Value 0-9


StokAwal Range Value 0-9

StokAkhir Range Value 0-9

AlasanPengambilan Range Value a-z, A-Z

5. Tabel InItem


InID autonumber

88

TanggalIn Range Value 0-9, ‘/’, “:”


POID Range Value a-z, A-Z, 0-9

Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

NamaPenerima Range Value a-z, A-Z


Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]


Qty Range Value 0-9


StokAwal Range Value 0-9

StokAkhir Range Value 0-9

6. Tabel PurchaseOrder



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

89

[0-9] [0-9] [0-9] [0-9]

TanggalPO Range Value 0-9, ‘/’

Format dd/mm/yy


Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]


Qty Range Value 0-9


Harga Range Value 0-9

SubTotal Range Value 0-9

Disc Range Value 0-9

GrandTotal Range Value 0-9

90

7. Tabel Hutang


HID autonumber


Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

JatuhTempo Range Value 0-9, ‘/’

Format dd/mm/yy

JumlahPembayaran Range Value 0-9

Status 0 or 1

8. Tabel ReturBarang


ReID autonumber

TanggalRetur Range Value 0-9, ‘/’, “:”



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]

91



Format [A-Z] [A-Z] [0-9] [0-9] [0-9] [0-9]

[0-9] [0-9] [0-9] [0-9]


Qty Range Value 0-9


AlasanRetur Range Value a-z, A-Z

3.2.1.5 Mengidentifikasi Atribut Candidate Key dan Primary Key

Tahapan ini bertujuan untuk menentukan candidate key

dan primary key untuk setiap entitas yang ada.

Tabel 3.3 Pemilihan Index No. Entitas Candidate Key Primary Key

1. Employee EmID EmID

2. Item BID BID

3. Supplier SupID SupID

4. OutItem OutID

EmID

BID

OutID

5. InItem InID

POID

SupID

BID

InID

6.

7.

8.

Purchase

Hutang

ReturBara

Gamba

Order

ang

ar 3.8 Entity

POID

EmID

SupID

BID

HID

POID

ReID

SupID

EmID

BID

y Relationshhip Diagram

POID

HID

ReID

dengan Priimary Key

92

93

3.2.1.6 Mempertimbangkan Konsep Pemodelan Enhanced (Optional)

Tujuan dari tahap ini adalah untuk mempertimbangkan

penggunaan konsep pemodelan enhanced, seperti spesialisasi,

generalisasi, agregasi, dan komposisi. Pada desain basisdata,

sejauh ini tidak ditemukan kebutuhan untuk menggunakan model

enhanced sehingga tahapan ini tidak dilakukan.

3.2.1.7 Memeriksa Model Terhadap Redundansi

Tujuan dari tahapan ini adalah untuk menghindari adanya

redundansi pada model data. Ada dua langkah yang dilakukan,

yaitu :

1. Memeriksa hubungan one-to-one relationship (1:1)

Dapat dilakukan dengan cara mengidentifikasikan

dua entitas yang sebenarnya memiliki arti yang sama,

namun dalam penulisan memiliki nama entitas yang

berbeda, dan kedua relasi memiliki hubungan one to one

(1:1). Kemudian dapat dilakukan penggabungan menjadi

satu entitas, di mana jika kedua entitas tersebut memiliki

primary key yang berbeda, maka harus dipilih satu primary

key untuk entitas yang dihasilkan dari penggabungan

tersebut.

Tetapi bila terdapat hubungan one to one (1:1)

dan kedua entitas tersebut tidak menggambarkan obyek

94

yang sama dalam perusahaan, maka kedua entitas tersebut

tidak dapat digabungkan. Contoh:

Relasi 1 : 1 Entitas PurchaseOrder dan Hutang

Gambar 3.9 Hubungan PurchaseOrder dan Hutang

Entitas PurchaseOrder dan Hutang mempunyai

hubungan one to one, namun obyek dari keduanya berbeda

dan tidak memiliki arti yang sama. Entitas PurchaseOrder

berisi pemesanan barang perusahaan kepada supplier,

sedangkan Hutang berisi keterangan mengenai

pembayaran yang harus dilakukan perusahaan yang

didapatkan dari purchase order, sehingga entitas ini tidak

dapat digabungkan.

Pada hubungan one to one (1:1) entitas

PurchaseOrder dan InItem keduanya juga tidak bisa

digabungkan. Entitas PurchaseOrder dan InItem tidak data

digabung karena pada PurchaseOrder dijelaskan barang

apa saja yang dipesan oleh perusahaan ke supplier,

sedangkan pada InItem dijelaskan mengenai barang apa

saja yang diterima oleh perusahaan dari pengiriman barang

supplier.

2.

3.2.1.8 M

Pe

m

di

Purchas

PK P

Gam

Mengh

adanya

Memvalidasi

engguna

Tujuan

model konse

ibutuhkan.

Gambar 3

1…1seOrder

OID

mbar 3.10 H

hilangan redu

Pada ER

a relasi yang

Model

n dari tahap

eptual telah

.11 ERD K

Men

Hubungan P

undansi rela

RD model k

g redundan.

Konseptua

pan ini adala

h mendukun

Konseptual d

nyebabkan1…

PurchaseOrd

asi

konseptual,

al Terhad

ah untuk me

ng transaks

dengan Use

1InItem

PK InID

der dan InIt

tidak ditem

dap Tran

emastikan b

i-transaksi

er Transactio

95

Item

mukan

saksi

ahwa

yang

on

96

Keterangan :

1. List karyawan.

2. List barang keluar.

3. List barang masuk.

4. List barang yang dimiliki.

5. List pembayaran yang harus dilakukan.

6. List purchase order.

7. List barang yang dikembalika atau retur.

8. List supplier.

9. Memberikan informasi barang yang diambil oleh karyawan.

10. Menampilkan informasi purchase order yang diberikan

kepada supplier.

11. Memberikan informasi karyawan yang menerima barang

masuk.

12. Memberikan informasi karyawan yang melakukan retur

barang.

13. Menampilkan informasi barang apa saja yang keluar dari

gudang.

14. Menampilkan informasi barang apa saja yang dikembalikan

atau retur.

15. Menampilkan informasi barang apa saja yang dipesan dalam

purchase order.

97

16. Memberikan informasi mengenai karyawan yang melakukan

purchase order.

17. Menampilkan informasi barang yang masuk berdasarkan

purchase order.

18. Menampilkan informasi pembayaran yang harus dilakukan

atau hutang berdasarkan purchase order.

19. Memberikan informasi mengenai barang yang masuk

berdasarkan supplier.

20. Memberikan informasi mengenai barang yang masuk ke

gudang.

21. Memberikan informasi retur barang yang dilakukan kepada

supplier.

3.2.1.9 Meninjau Kembali Model Data Konseptual Dengan Pengguna

Tujuan dari tahapan ini adalah untuk memastikan bahwa

model data tersebut secara tepat menggambarkan transaksi dan

kebutuhan data secara nyata dalam perusahaan. Model data yang

telah dibuat dirasa sudah sudah cukup mendukung kebutuhan PT.

Langgeng Pranamas Sentosa.

98

3.2.2 Perancangan Basis Data Logikal

Perancangan basis data logikal merupakan suatu proses

membangun model informasi yang digunakan dalam perusahaan

berdasarkan model data yang spesifik, tetapi independen terhadap

berbagai jenis DBMS dan pertimbangan fisikal lainnya. Langkah-langkah

dalam perancangan basis data logikal :

1. Menghilangkan fitur yang tidak sesuai dengan model relasional.

2. Membuat relasi untuk model data logikal lokal.

3. Memvalidasikan relasi menggunakan normalisasi.

4. Memvalidasi relasi terhadap transaksi pengguna.

5. Menentukan batasan integritas.

6. Memeriksa model data logikal dengan pengguna.

7. Menggabungkan model data logikal lokal ke dalam model data

logikal global.

8. Memeriksa terhadap pertumbuhan di masa mendatang.

3.2.2.1 Menghilangkan Fitur Yang Tidak Sesuai Dengan Model

Relasional

a. Menghilangkan relasi binary many-to-many (*:*)

1. Hubungan (*:*) InItem dan Item menghasilkan entitas

baru bernama InDetail.

99

Gambar 3.12 Menghilangkan Hubungan antara InItem dengan Item

2. Hubungan (*:*) OutItem dan Item menghasilkan entitas

baru bernama OutDetail.

Gambar 3.13 Menghilangkan Hubungan antara OutItem dengan Item

3. Hubungan (*:*) ReturBarang dan Item menghasilkan

entitas baru bernama ReturDetail.

Gambar 3.14 Menghilangkan Hubungan antara ReturBarang

dengan Item

4. Hubungan (*:*) PurchaseOrder dan Item menghasilkan

entitas baru bernama PODetail.

100

Gambar 3.15 Menghilangkan Hubungan antara PurchaseOrder

dengan Item

b. Menghilangkan tipe relasi rekursif many-to-many (*:*)

1. Employee

Gambar 3.16 Menghilangkan Relasi Rekursif (*:*) Employee

101

2. Item

Gambar 3.17 Menghilangkan Relasi Rekursif (*:*) Item

3. Supplier

Gambar 3.18 Menghilangkan Relasi Rekursif (*:*) Supplier

102

4. Menghilangkan tipe relasi kompleks

Dalam pemodelan logikal data lokal, tidak ditemukan

adanya tipe relasi kompleks.

5. Menghilangkan atribut multi-valued


adanya multi-valued attributes.

3.2.2.2 Membuat Relasi Untuk Model Data Logikal Lokal

a. Tipe Entitas Kuat

Entitas kuat merupakan entitas yang dapat berdiri

sendiri dan tidak bergantung pada entitas lainnya, yang

termasuk di antaranya adalah :

1. Employee (EmID, UserID, NamaKaryawan,

AlamatKaryawan, TelpKaryawan, EmailKaryawan,

Jabatan)

Primary Key EmID

2. Item (BID, NamaBarang, Stock, Unit, MinimumStock,

JenisBarang )

Primary Key BID

3. Supplier (SupID, NamaSupplier, AlamatSupplier,

TelpSupplier, HPSupplier, JenisSupplier)

Primary Key SupID

103

b. Tipe Entitas Lemah

Merupakan kebalikan dari tipe entitas kuat, di mana

entitas ini memiliki ketergantungan terhadap entitas lain,

yang termasuk di antaranya adalah :

1. OutItem (OutID, TanggalOut, EmID, NamaKaryawan,

NamaAccepter, BID, NamaBarang, Qty, Unit, StokAwal,

StokAkhir, AlasanPengambilan)

Primary Key OutID

2. OutDetail (OutID, BID, NamaBarang, Qty, Unit,

StokAwal, StokAkhir)

Primary Key OutID, BID

3. InItem (InID, TanggalIn, POID, EmID, NamaPenerima,

SupID, NamaSupplier, BID, NamaBarang, Qty, Unit,

StokAwal, StokAkhir)

Primary Key InID

4. InDetail (InID, BID, NamaBarang, Qty, Unit, StokAwal,

StokAkhir)

Primary Key InID, BID

5. Purchase Order (POID, TanggalPO, EmID,

NamaKaryawan, SupID, NamaSupplier, BID,

NamaBarang, Qty, Unit, Harga, SubTotal, Disc,

GrandTotal)

Primary Key POID

104

6. PODetail (POID, BID, NamaBarang, Qty, Unit, Harga,

SubTotal)

Primary Key POID, BID

7. Hutang(HID, POID, JatuhTempo, JumlahPembayaran,

Status)

Primary Key HID

8. ReturBarang (ReID, TanggalRetur, SupID,

NamaSupplier, EmID, NamaKaryawan, BID,

NamaBarang, Qty, Unit, AlasanRetur)

Primary Key ReID

9. ReturDetail (ReID, BID, NamaBarang, Qty, Unit,

AlasanRetur)

Primary Key ReID, BID

10. SubItem (JBID, JenisBarang, IDesc)

Primary Key JBID

11. Posisi (PosID, Jabatan)

Primary Key PID

12. SubSupplier (JSID, JenisSupplier, SDesc)

Primary Key JSID

105

c. Mengidentifikasi Tipe Relasi Biner One to One (1:1)

1. Hubungan antara PurchaseOrder dengan Hutang

2. Hubungan antara PurchaseOrder dengan InItem.

106

d. Mengidentifikasi Tipe Relasi Biner One to Many (1:*)

1. Hubungan antara Employee dengan OutItem

2. Hubungan antara Employee dengan InItem

107

3. Hubungan antara Employee dengan ReturBarang

4. Hubungan antara Employee dengan PurchaseOrder

108

5. Hubungan antara Supplier dengan PurchaseOrder

6. Hubungan antara Supplier dengan ReturBarang

109

7. Hubungan antara Supplier dengan InItem

e. Mengidentifikasi Tipe Relasi Biner Many to Many (*:*)

a. Hubungan antara OutItem dengan Item

OutItem (OutID, TanggalOut, EmID, NamaKaryawan, NamaAccepter, BID, NamaBarang, Qty, Unit, StokAwal, StokAkhir, AlasanPengambilan) Primary Key OutID Foreign Key EmID references Employee (EmID) Foreign Key BID references Item (BID)

Item (BID, NamaBarang, Stock, Unit, MinimumStock, JenisBarang) Primary Key BID

OutDetail (OutID, BID, NamaBarang, Qty, Unit, StokAwal, StokAkhir) Primary Key OutID, BID Foreign Key OutID references OutItem (OutID) Foreign Key BID references Item (BID)

110

b. Hubungan antara InItem dengan Item

InItem (InID, TanggalIn, POID, EmID, NamaPenerima, SupID, NamaSupplier, BID, NamaBarang, Qty, Unit, StokAwal, StokAkhir) Primary Key InID Foreign Key POID references PurchaseOrder (POID) Foreign Key EmID references Employee (EmID) Foreign Key SupID references Supplier (SupID) Foreign Key BID references Item (BID)


InDetail (InID, BID, NamaBarang, Qty, Unit, StokAwal, StokAkhir) Primary Key InID, BID Foreign Key InID references InItem (InID) Foreign Key BID references Item (BID)

c. Hubungan antara ReturBarang dengan Item

ReturBarang (ReID, TanggalRetur, SupID, NamaSupplier, EmID, NamaKaryawan, BID, NamaBarang, Qty, Unit, AlasanRetur) Primary Key ReID Foreign Key EmID references Employee (EmID) Foreign Key SupID references Supplier (SupID) Foreign Key BID references Item (BID)


ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur) Primary Key ReID, BID Foreign Key ReID references ReturBarang (ReID) Foreign Key BID references Item (BID)

111

d. Hubungan antara PurchaseOrder dengan Item

PurchaseOrder (POID, TanggalPO, EmID, NamaKaryawan, SupID, NamaSupplier, BID, NamaBarang, Qty, Unit, Harga, SubTotal, Disc, GrandTotal) Primary Key POID Foreign Key EmID references Employee (EmID) Foreign Key SupID references Supplier (SupID) Foreign Key BID references Item (BID)


PODetail (POID, BID, NamaBarang, Qty, Unit, Harga, SubTotal)

Primary Key POID, BID Foreign Key POID references PurchaseOrder (POID) Foreign Key BID references Item (BID)

f. Mengidentifikasi Atribut Multi-Valued


adanya multi-valued attributes.

112

Gambar 3.19 ERD Logikal Belum Normal

3.2.2.3 Memvalidasikan Relasi Menggunakan Normalisasi

Tahapan ini bertujuan untuk memvalidasi relasi dalam

model data logikal lokal menggunakan teknik normalisasi.

113

a. Employee

2NF

Employee (EmID, UserID, NamaKaryawan, AlamatKaryawan, TelpKaryawan,

EmailKaryawan, Jabatan)

Tabel 3.4 Normalisasi Entitas Employee

1NF

Menentukan primary key yaitu EmID. Dalam relasi tidak terdapat repeating group, derived attribute, sehingga relasi telah berada pada kondisi 1NF.

2NF

Dalam relasi tidak terdapat ketergantungan parsial sehingga relasi telah berada pada kondisi 2NF.

3NF

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF. Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan, EmailKaryawan,PosID, UserID) Posisi (PosID, Jabatan) User (UserID, Username, Password)

b. Item

2NF

Item (BID, NamaBarang, Stock, Unit, MinimumStock, JenisBarang )

Tabel 3.5 Normalisasi Entitas Item

1NF

Menentukan primary key yaitu BID. Dalam relasi tidak

2NF

Dalam relasi tidak terdapat ketergantungan parsial sehingga relasi telah

3NF

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF.

114

terdapat repeating group, derived attribute, sehingga relasi telah berada pada kondisi 1NF.

berada pada kondisi 2NF.

Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID ) SubItem (JBID, JenisBarang, IDesc)

c. Supplier

2NF

Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier,

JenisSupplier)

Tabel 3.6 Normalisasi Entitas Supplier

1NF

Menentukan primary key yaitu SupID. Dalam relasi tidak terdapat repeating group, derived attribute, sehingga relasi telah berada pada kondisi 1NF.

2NF


3NF

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF. Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier, JSID) SubSupplier (JSID, JenisSupplier, SDesc)

d. OutItem

UNF

OutItem (OutID, TanggalOut, EmID, NamaKaryawan, NamaAccepter, {BID,

NamaBarang, Qty, Unit, StokAwal, StokAkhir}, AlasanPengambilan)

Tabel 3.7 Normalisasi Entitas OutItem

1NF

Menentukan primary

2NF

Dalam relasi terdapat

3NF

Dalam relasi terdapat

115

key yaitu OutID. Dalam relasi terdapat repeating group, derived attribute, sehingga perlu dilakukan normalisasi 1NF. OutItem (OutID, TanggalOut, EmID, NamaKaryawan, NamaAccepter, AlasanPengambilan) OutDetail (OutID, BID, NamaBarang, Qty, Unit)

ketergantungan parsial sehingga perlu dilakukan normalisasi 2NF. OutDetail (OutID, BID, Qty, Unit) Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID )

ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF.

OutItem (OutID, TanggalOut, EmID, NamaAccepter, AlasanPengambilan) Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan, EmailKaryawan,PosID, UserID)

e. PurchaseOrder

UNF

PurchaseOrder (POID, TanggalPO, EmID, NamaKaryawan, SupID,

NamaSupplier, {BID, NamaBarang, Qty, Unit, Harga, SubTotal}, Disc,

GrandTotal)

Tabel 3.8 Normalisasi Entitas PurchaseOrder

1NF

Menentukan primary key yaitu POID. Dalam relasi terdapat repeating group, derived attribute, sehingga perlu dilakukan normalisasi 1NF. PurchaseOrder (POID, TanggalPO, EmID, NamaKaryawan, SupID,

2NF

Dalam relasi terdapat ketergantungan parsial sehingga perlu dilakukan normalisasi 2NF. PODetail (POID, BID, Qty, Unit, Harga) Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID )

3NF


PurchaseOrder (POID, TanggalPO, EmID, SupID) Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan,

116

NamaSupplier) PODetail (POID, BID, NamaBarang, Qty, Unit, Harga)

EmailKaryawan,PosID, UserID) Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier, JSID)

f. InItem

UNF

InItem (InID, TanggalIn, POID, EmID, NamaPenerima, SupID, NamaSupplier,

{BID, NamaBarang, Qty, Unit, StokAwal, StokAkhir})

Tabel 3.9 Normalisasi Entitas InItem

1NF

Menentukan primary key yaitu InID. Dalam relasi terdapat repeating group, derived attribute, sehingga perlu dilakukan normalisasi 1NF. InItem (InID, TanggalIn, POID, EmID, NamaPenerima, SupID, NamaSupplier) InDetail (InID, BID, NamaBarang, Qty, Unit)

2NF

Dalam relasi terdapat ketergantungan parsial sehingga perlu dilakukan normalisasi 2NF. InDetail (InID, BID, Qty, Unit) Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID )

3NF


InItem (InID, TanggalIn, POID, EmID, SupID) PurchaseOrder (POID, TanggalPO, EmID, SupID) Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan, EmailKaryawan,PosID, UserID) Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier, JSID)

117

g. Hutang

2NF

Hutang (HID, POID, JatuhTempo, JumlahPembayaran,Status)

Tabel 3.10 Normalisasi Entitas Hutang

1NF

Menentukan primary key yaitu HID. Dalam relasi tidak terdapat repeating group, derived attribute, sehingga relasi telah berada pada kondisi 1NF.

2NF


3NF


Hutang (HID, POID, JatuhTempo, JumlahPembayaran, Status) PurchaseOrder (POID, TanggalPO, EmID, SupID)

h. ReturBarang

UNF

ReturBarang (ReID, TanggalRetur, SupID, NamaSupplier, EmID,

NamaKaryawan, {BID, NamaBarang, Qty, Unit, AlasanRetur})

Tabel 3.11 Normalisasi Entitas Retur Barang

1NF

Menentukan primary key yaitu ReID. Dalam relasi terdapat repeating group, derived attribute, sehingga perlu dilakukan normalisasi 1NF. ReturBarang (ReID,

2NF

Dalam relasi terdapat ketergantungan parsial sehingga perlu dilakukan normalisasi 2NF. ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur)

3NF


ReturBarang (ReID, TanggalRetur, SupID, EmID)

118

TanggalRetur, SupID, NamaSupplier, EmID, NamaKaryawan) ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur)

Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID )

Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan, EmailKaryawan,PosID, UserID)

Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier, JSID)

3.2.2.4 Memvalidasi Relasi Terhadap Transaksi Pengguna

Gambar 3.20 Validasi Relasi melalui Transaksi Pengguna

119

Keterangan :

a. Menampilkan informasi barang yang ada di gudang.

b. Menampilkan data-data barang yang keluar dari gudang dan jumlah stok

setelah proses, serta untuk menghasil laporan barang keluar.

c. Menampilkan informasi mengenai karyawan yang bertanggung jawab

melakukan pengambilan barang.

d. Menampilkan data-data barang yang masuk ke gudang dan jumlah stok

setelah proses, serta untuk menghasil laporan barang masuk.

e. Menampilkan informasi supplier.

f. Menampilkan informasi mengenai supplier yang mendapatkan retur

barang.

g. Menampilkan informasi mengenai karyawan yang yang bertanggung jawab

melakukan penerimaan barang yang masuk ke gudang.

h. Menampilkan informasi mengenai karyawan yang bekerja di perusahaan.

i. Menampilkan informasi karyawan yang yang bertanggung jawab

melakukan retur barang.

j. Menampilkan informasi mengenai supplier yang melakukan pengiriman

barang.

k. Menghasilkan laporan hutang perusahaan melalui data-data purchase order.

l. Menampilkan data-data barang yang di retur ke supplier.

m. Menampilkan informasi mengenai purchase order yang masuk ke gudang.

n. Menampilkan informasi mengenai purchase order yang sudah dilakukan.

120

3.2.2.5 Menentukan Batasan Integritas

Tahapan ini bertujuan untuk menentukan batasan

integritas yang ada pada model data logikal lokal untuk

melindungi basis data dari keadaan yang tidak konsisten. Batasan-

batasan integritas tersebut, antara lain :

1. Data yang dibutuhkan

Beberapa atribut harus memiliki nilai yang valid, dengan kata

lain, atribut tersebut tidak boleh null. Batasan ini telah

diidentifikasi dalam perancangan basis data konseptual tahap

ketiga.

2. Batasan domain atribut

Setiap atribut memiliki sebuah domain, yaitu sekumpulan

nilai yang legal. Batasan ini telah diidentifikasi dalam

perancangan basis data konseptual tahap keempat.

3. Integritas entitas

Primary key dari sebuah entitas tidak boleh null. Batasan ini

sudah diidentifikasi dalam perancangan basis data konseptual

tahap kelima.

4. Integritas referensial

Integritas referensial berarti bahwa jika dalam suatu entitas

terdapat foreign key yang mengandung suatu nilai, maka nilai

tersebut harus merujuk pada baris yang ada pada relasi parent.

121

Tabel 3.12 Referential Integrity Constraint

Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan, EmailKaryawan, PosID, UserID) Primary Key EmID Foreign Key PID references Posisi(PosID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key UserID references User(UserID) ON UPDATE CASCADE ON DELETE NO ACTION Item (BID, NamaBarang, Stock, Unit, MinimumStock, JBID ) Primary Key BID Foreign Key JBID references SubItem(JBID) ON UPDATE CASCADE ON DELETE NO ACTION Supplier (SupID, NamaSupplier, AlamatSupplier, TelpSupplier, HPSupplier, JSID) Primary Key SupID Foreign Key JSID references SubSupplier(JSID) ON UPDATE CASCADE ON DELETE NO ACTION OutItem (OutID, TanggalOut, EmID, NamaAccepter, AlasanPengambilan) Primary Key OutID Foreign Key EmID references Employee(EmID) ON UPDATE CASCADE ON DELETE NO ACTION OutDetail (OutID, BID, Qty, Unit) Primary Key OutID,BID Foreign Key OutID references OutItem(OutID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key BID references Item(BID) ON UPDATE CASCADE ON DELETE NO ACTION PurchaseOrder (POID, TanggalPO, EmID, SupID) Primary Key POID Foreign Key EmID references Employee(EmID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key SupID references Supplier(SupID) ON UPDATE CASCADE ON DELETE NO ACTION PODetail (POID, BID, Qty, Unit, Harga) Primary Key POID, BID Foreign Key POID references PurchaseOrder(POID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key BID references Item(BID) ON UPDATE CASCADE ON DELETE NO ACTION InItem (InID, TanggalIn, POID, EmID, SupID) Primary Key InID Foreign Key POID references PurchaseOrder(POID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key EmID references Employee(EmID) ON UPDATE CASCADE ON DELETE NO ACTION

122

Foreign Key POID references Supplier(SupID) ON UPDATE CASCADE ON DELETE NO ACTION InDetail (InID, BID, Qty, Unit) Primary Key InID, BID Foreign Key InID references InItem(InID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key BID references Item(BID) ON UPDATE CASCADE ON DELETE NO ACTION Hutang (HID, POID, JatuhTempo, JumlahPembayaran, Status) Primary Key HID Foreign Key POID references PurchaseOrder(POID) ON UPDATE CASCADE ON DELETE NO ACTION ReturBarang (ReID, TanggalRetur, SupID, EmID) Primary Key ReID Foreign Key SupID references Supplier(EID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key EmID references Employee(EmID) ON UPDATE CASCADE ON DELETE NO ACTION ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur) Primary Key ReID, BID Foreign Key ReID references ReturBarang(ReID) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key BID references Item(BID) ON UPDATE CASCADE ON DELETE NO ACTION

3.2.2.6 Memeriksa Model Data Logikal Dengan Pengguna

Tahapan ini bertujuan untuk meninjau kembali dan

memastikan bahwa model data logikal lokal sudah merupakan

representasi yang benar dari kebutuhan-kebutuhan data

perusahaan.

3.2.2.7 Menggabungkan Model Data Logikal Lokal ke Dalam Model

Data Logikal Global

Tahapan ini bertujuan untuk menggabungkan model data

logikal lokal yang ada menjadi sebuah model data logikal global

perusahaan. Dalam perancangan ini hanya menggunakan satu

123

view yang merepresentasikan model data lokal, oleh karena itu

tidak perlu dilakukan penggabungan model data lokal karena

model data lokal akan langsung menjadi model data global. Lihat

gambar 3.21.

3.2.3.8 Memeriksa Terhadap Pertumbuhan di Masa Mendatang

Tahapan ini bertujuan untuk menentukan apakah

rancangan basis data yang telah dibuat masih memungkinkan

diperbarui untuk kebutuhan baru di masa mendatang. Seperti, jika

perusahaan menginginkan sistem informasi penggajian karyawan

atau sistem pengiriman barang, maka rancangan basis data ini

masih dapat dikembangkan lagi sesuai kebutuhan perusahaan.

124

Gambar 3.21 ERD Logikal Global

125

3.2.3 Perancangan Basis Data Fisikal

Perancangan basis data fisikal adalah proses penggambaran dari

implementasi basis data pada media penyimpanan yang menggambarkan

relasi dasar, organisasi file, dan indeks yang memungkinkan data diakses

dengan lebih efisien, serta berbagai batasan integritas yang berhubungan

dan ukuran keamanan lainnya. Langkah-langkah dalam perancangan

basis data fisikal :

1. Merancang relasi dasar

2. Merancang representasi data turunan(derived data)

3. Merancang batasan perusahaan

4. Menganalisa transaksi

5. Memilih organisasi file

6. Pemilihan index

7. Memperkirakan kebutuhan kapasitas penyimpanan

8. Merancang user view

9. Merancang mekanisme keamanan

3.2.3.1 Merancangan Relasi Dasar

Tahapan ini bertujuan untuk mengidentifikasikan basis

data relasional dalam model data logikal global yang

digunakan dalam DBMS dengan menggunakan DBDL

(Database Design Language).

126

Berikut ini merupakan perancangan DBDL (Database

Design Language) untuk setiap entitas :

1. DBDL Employee

Domain EmID : Fixed length character string, length 10

Domain NamaKaryawan : Variable length character string, length 50

Domain AlamatKaryawan : Variable length character string, length 60

Domain TelpKaryawan : Variable length character string, length 15

Domain EmailKaryawan : Variable length character string, length 30

Domain UserID : Integer, length 11

Domain PosID : Integer, length 11

Employee (

EmID EmID NOT NULL,

Namakaryawan NamaKaryawan NOT NULL,

AlamatKaryawan AlamatKaryawan NOT NULL,

TelpKaryawan TelpKaryawan NULL,

EmailKaryawan EmailKaryawan NULL,

UserID UserID NULL,

PosID PosID NOT NULL,

Primary Key (EmID),

Foreign Key UserID references User (UserID) ON UPDATE

CASCADE ON DELETE NO ACTION,

Foreign Key PosID references Posisi (PosID) ON UPDATE


127

2. DBDL Item

Domain BID : Fixed length character string, length 10

Domain NamaBarang : Variable length character string, length 30

Domain Stock : Integer, length 11

Domain Unit : Variable length character string, length 10

Domain MinimumStock : Integer, length 11

Domain JBID : Integer, length 11

Item (

BID BID NOT NULL

NamaBarang NamaBarang NOT NULL,

Stock Stock NOT NULL,

Unit Unit NOT NULL,

MinimumStock MinimumStock NOT NULL,

JBID JBID NOT NULL,

Primary Key (BID),

Foreign Key JBID references SubItem (JBID) ON UPDATE

CASCADE ON DELETE NO ACTION

);

3. DBDL Supplier

Domain SupID : Fixed length character string, length 10

Domain NamaSupplier : Variable length character string, length 50

Domain AlamatSupplier : Variable length character string, length 60

128

Domain TelpSupplier : Variable length character string, length 15

Domain HPSupplier : Variable length character string, length 15

Domain JSID : Integer, length 11

Supplier (

SupID IID NOTNULL,

NamaSupplier NamaSupplier NOT NULL,

AlamatSupplier AlamatSupplier NOT NULL,

TelpSupplier TelpSupplier NOT NULL,

HPSupplier HPSupplier NULL,

JSID JSID NOT NULL,

Primary Key (SupID),

Foreign Key JSID references SubSupplier(JSID) ON UPDATE


);

4. DBDL User

Domain UserID : Integer, length 11

Domain Username : Variable length character string, length 25

Domain Password : Variable length character string, length 30

User (

UserID UserID NOT NULL auto_increment,

Username Username NOT NULL,

Password Password NOT NULL,

129

Primary Key (UserID),

);

5. DBDL Posisi

Domain PosID : Integer, length 11

Domain Jabatan : Variable length varchar string, length 30

Posisi (

PosID PosID NOT NULL auto_increment,

Jabatan Jabatan NOT NULL,

Primary Key (PosID),

);

6. DBDL SubItem

Domain JBID : Integer, length 11

Domain JenisBarang : Variable length character string, length 25

Domain IDesc : Variable length character string, length 100

SubItem (

JBID JBID NOT NULL auto_increment,

JenisBarang JenisBarang NOT NULL,

IDesc IDesc NOT NULL,

Primary Key (JBID),

);

130

7. DBDL SubSupplier

Domain JSID : Integer, length 11

Domain JenisSupplier : Variable length character string, length 25

Domain SDesc : Variable length character string, length 100

Position (

JSID JSID NOT NULL auto_increment,

JenisSupplier JenisSupplier NOT NULL,

SDesc SDesc NOTNULL,

Primary Key (JSID)

);

8. DBDL OutItem

Domain OutID : Integer, length 11


Domain NamaAccepter : Variable length character string, length 50

Domain TanggalOut : Datetime

Domain AlasanPengambilan : Variable length character string, length

100

OutItem (

OutID OutID NOT NULL auto_increment,

EmID EmID NOT NULL,

NamaAccepter NamaAccepter NOT NULL,

TanggalOut TanggalOut NOT NULL,

131

AlasanPengambilan AlasanPengambilan NOT NULL,

Primary Key (OutID),

Foreign Key EmID references Employee(EmID) ON UPDATE


);

9. DBDL OutDetail

Domain OutID : Integer, length 11


Domain Qty : Integer, length 11


OutDetail (

OutID OutID NOT NULL,

BID BID NOT NULL,

Qty Qty NOT NULL,

Unit Unit NOT NULL,

Primary Key (OutID, BID)

Foreign Key OutID references OutItem (OutID) ON UPDATE


Foreign Key BID references Item(BID) ON UPDATE CASCADE

ON DELETE NO ACTION,

);

132

10. DBDL PurchaseOrder

Domain POID : Fixed length character string, length 10



Domain TanggalPO : Date

PurchaseOrder (

POID POID NOT NULL,

EmID EmID NOT NULL,

SupID SupID NOT NULL,

TanggalPO TanggalPO NOTNULL,

Primary Key (POID)



Foreign Key SupID references Supplier(SupID) ON UPDATE


);

11. DBDL PODetail





Domain Harga : Decimal (20, 2)

133

PODetail (

POID POID NOT NULL

BID BID NOT NULL,

Qty Qty NOT NULL,

Unit Unit NOT NULL,

Harga Harga NOT NULL,

Primary Key (POID, BID),

Foreign Key POID references PurchaseOrder (POID) ON UPDATE


Foreign Key BID references Item (BID) ON UPDATE CASCADE

ON DELETE NO ACTION

);

12. DBDL InItem

Domain InID : Integer, length 11




Domain TanggalIn : Datetime

InItem (

InID InID NOT NULL auto_increment,

POID POID NOT NULL,

EmID EmID NOT NULL,

134


TanggalIn TanggalIn NOT NULL,

Primary Key (InID)

Foreign Key POID references PurchaseOrder (POID) ON UPDATE


Foreign Key EmID references Employee (EmID) ON UPDATE


Foreign Key SupID references Supplier (SupID) ON UPDATE


);

13. DBDL InDetail

Domain InID : Integer, length 11




InDetail (

InID InID NOT NULL,

BID BID NOT NULL,

Qty Qty NOT NULL,

Unit Unit NOT NULL,

Primary Key (InID, BID)

135

Foreign Key InID references InItem (InID) ON UPDATE


Foreign Key BID references Item (BID) ON UPDATE CASCADE

ON DELETE NO ACTION

);

14. DBDL Hutang

Domain HID : Integer, length 11


Domain JatuhTempo : Date

Domain JumlahPembayaran : Decimal (20, 2)

Domain Status : Variable length character string, length 2

Hutang (

HID HID NOT NULL auto_increment,

POID POID NOT NULL,

JatuhTempo JatuhTempo NOT NULL,

JumlahPembayaran JumlahPembayaran NOT NULL,

Status Status NOT NULL,

Primary Key (HID),

Foreign Key POID references PurchaseOrder(POID) ON UPDATE


);

136

15. DBDL ReturBarang

Domain ReID : Integer, length 11



Domain TanggalRetur : Date

ReturBarang (

ReID ReID NOT NULL,


EmID EmID NOT NULL,

TanggalRetur TanggalRetur NOT NULL,

Primary Key (ReID),

Foreign Key SupID references Supplier(SupID) ON UPDATE




);

16. DBDL ReturDetail

Domain ReID : Integer, length 11




Domain AlasanRetur : Variable length character string, length 100

137

ReturDetail (

ReID ReID NOT NULL,

BID BID NOT NULL,

Qty Qty NOT NULL,

Unit Unit NOT NULL,

AlasanRetur AlasanRetur NOT NULL,

Primary Key (ReID, BID),

Foreign Key ReID references ReturBarang(ReID) ON UPDATE


Foreign Key BID references Item(BID) ON UPDATE CASCADE

ON DELETE NO ACTION

);

3.2.3.2 Merancang Representasi Data Turunan (Derived Data)

Tahapan ini bertujuan untuk memutuskan bagaimana

merepresentasi data turunan yang ada dalam data model logikal

global pada DBMS yang digunakan. Dalam model data yang

dibangun, tidak dibutuhkan data turunan.

3.2.3.3 Merancang Batasan Perusahaan

Tujuan dari tahap ini adalah merancang batasan-batasan

perusahaan untuk DBMS yang akan digunakan. Berikut ini

didefinisikan batasan-batasan yang ditentukan :

138

1. Validitas kuantitas item yang diambil

Kuantitas barang yang keluar tidak boleh melebihi kuantitas

barang yang ada.

2. Validitas kuantitas material yang diretur

Kuantitas barang yang diretur tidak boleh melebihi kuantitas

barang yang ada.

3. Validitas jumlah pembayaran hutang

Jumlah pembayaran hutang tidak boleh melebihi jumlah

pembayaran purchase order.

3.2.3.4 Analisa Transaksi

Tahapan ini bertujuan untuk memahami

fungsionalitas dari setiap transaksi yang akan berjalan

pada basis data dan untuk menganalisa transaksi

penting yang terjadi.

Langkah-langkah yang dilakukan dalam analisa

transaksi, yaitu :

1. Memetakan semua jalur transaksi dalam relasi.

2. Menentukan relasi mana yang paling sering diakses

oleh transaksi.

3. Menganalisa penggunaan data dari relasi yang

dipilih pada langkah sebelumnya.

139

Berikut ini adalah transaksi yang dilakukan :

a. Input / Ubah data Item

b. Input / Ubah data Employee

c. Input / Ubah data Supplier

d. Tampilkan data Barang

Tabel 3.13a Analisa Transaksi

User Relation

a b c d R U D I R U D I R U D I R U D I

Employee X X X Item X X X X

Supplier X X X User X X Posisi X X X

SubItem X X X X SubSupplier X X X

OutItem OutDetail

PurchaseOrder PODetail InItem

InDetail Hutang

ReturBarang ReturDetail

Keterangan : R = Read, U = Update, D =Delete, I = Insert

e. Tampilkan data Karyawan

f. Tampilkan data Supplier

g. Input dan tampilkan data InItem

h. Input dan tampilkan data OutItem

140

Tabel 3.13b Analisa Transaksi

User Relation

e f g h R U D I R U D I R U D I R U D I

Employee X X X Item X X

Supplier X X User X Posisi X

SubItem X X SubSupplier X

OutItem X X OutDetail X X

PurchaseOrder X PODetail InItem X X

InDetail X X Hutang

ReturBarang ReturDetail


i. Input dan tampilkan data Purchase Order

j. Input dan tampilkan Hutang

k. Input dan tampilkan data Retur Barang

Tabel 3.13c Analisa Transaksi

User Relation

i j k R U D I R U D I R U D I

Employee X X Item X X

Supplier X X User Posisi

SubItem X X SubSupplier

OutItem

141

OutDetail PurchaseOrder X X X X

PODetail X X InItem

InDetail Hutang X X

ReturBarang X X ReturDetail X X


3.2.3.5 Pemilihan Organisasi File

Tahapa ini bertujuan untuk menentukan sebuah organisasi

file yang efisien untuk setiap relasi dasar. DBMS yang digunakan

dalam perancangan basisdata inventory PT. LANGGENG

PRANAMAS SENTOSA adalah MySQL. Tipe organisasi file

dari MySQL yaitu B-tree. B tree adalah sebuah pohon struktur

data yang menyimpan data yang diurutkan dan memungkinkan

pencarian, akses sekuensial, sisipan dan penghapusan dalam

waktu diamortisasi logaritmik. B-tree dioptimalkan untuk sistem

yang membaca dan menulis blok yang besar.

142

3.2.3.6 Pemilihan Index

Tahapan ini bertujuan untuk menentukan apakah

penambahan index akan meningkatkan performa dari sistem.

Tabel 3.14 Pemilihan Index Cluster atau Noncluster

Tabel Nama Index Field

Employee Idx_EmID (Clustered indeks) EmID

Item Idx_BID (Clustered indeks) BID

Supplier Idx_SupID (Clustered indeks) SupID

OutItem Idx_OutID (Clustered indeks) OutID

InItem Idx_InID (Clustered indeks) InID

User Idx_UserID (Clustered indeks) UserID

Posisi Idx_PosID (Clustered indeks) PosID

SubItem Idx_JBID (Clustered indeks) JBID

SubSupplier Idx_JSID (Clustered indeks) JSID

OutDetail Idx_OutID (Clustered indeks) OutID

InDetail Idx_InID (Clustered indeks) InID

PurchaseOrder Idx_POID (Clustered indeks) POID

PODetail Idx_POID (Clustered indeks) POID

Hutang Idx_HID (Clustered indeks) HID

ReturBarang Idx_ReID (Clustered indeks) ReID

ReturDetail Idx_ReID (Clustered indeks) ReID

143

3.2.3.7 Estimasi Kebutuhan Media Penyimpanan

Tahapan ini bertujuan untuk memperkirakan

kapasitas penyimpanan yang akan dibutuhkan oleh

basis data.

Estimasi dari kebutuhan media penyimpanan

adalah sebagai berikut :

1. Employee

Atribut Tipe Data Ukuran

EmID Char (10) 10

NamaKaryawan Varchar (50) 50

AlamatKaryawan Varchar (60) 60

TelpKaryawan Varchar (15) 15

EmailKaryawan Varchar (30) 30

UserID Integer 4

PosID Integer 4

Jumlah = 173 byte

2. Item


BID Char (10) 10

NamaBarang Varchar (30) 30

Stock Integer 4

Unit Varchar (10) 10

MinimumStock Integer 4

JBID Integer 4

Jumlah = 62 byte

144

3. Supplier


SupID Char (10) 10

NamaSupplier Varchar (50) 50

AlamatSupplier Varchar (60) 60

TelpSupplier Varchar (15) 15

HPSupplier Varchar (15) 15

JSID Integer 4

Jumlah = 154 byte

4. User


UserID Integer 4

Username Varchar (25) 25

Password Varchar (30) 30

Jumlah = 59 byte

5. Posisi


PosID Integer 4

Jabatan Varchar (30) 30

Jumlah = 34 byte

6. SubItem


JBID Integer 4

JenisBarang Varchar (25) 25

IDesc Varchar (100) 100

Jumlah = 129 byte

145

7. SubSupplier


JSID Integer 4

JenisSupplier Varchar (25) 25

SDesc Varchar (100) 100

Jumlah = 129 byte

8. OutItem


OutID Integer 4

EmID Char (10) 10

NamaAccepter Varchar (50) 50

TanggalOut DateTime 8

AlasanPengambilan Varchar (100) 100

Jumlah = 172 byte

9. OutDetail


OutID Integer 4

BID Char (10) 10

Qty Integer 4


Jumlah = 28 byte

10. PurchaseOrder


POID Char (10) 10

EmID Char (10) 10

146

SupID Char (10) 10

TanggalPO Date 3

Jumlah = 33 byte

11. PODetail


POID Char (10) 10

BID Char (10) 10

Qty Integer 4


Harga Decimal (20, 2) 20

Jumlah = 54 byte

12. InItem


InID Integer 4

POID Char (10) 10

EmID Char (10) 10

SupID Char (10) 10

TanggalIn Datetime 8

Jumlah = 42 byte

13. InDetail


InID Integer 4

BID Char (10) 10

Qty Integer 4


Jumlah = 28 byte

147

14. Hutang


HID Integer 4

POID Char (10) 10

JatuhTempo Date 3

JumlahPembayaran Decimal (20, 2) 20

Jumlah = 37 byte

15. ReturBarang


ReID Integer 4

SupID Char (10) 10

EmID Char (10) 10

TanggalRetur Date 3

Jumlah = 27 byte

16. ReturDetail


ReID Integer 4

BID Char (10) 10

Qty Integer 4


Jumlah = 28 byte

Dari tabel di atas, diperkirakan besar ukuran

record yang dapat digunakan untuk transaksi yang

dilakukan setiap harinya adalah :

148

Tabel 3.15 Perkiraan Ukuran Record Transaksi

Tabel Size 1 Record

(byte)

Perkiraan

Transaksi Perbulan

Size Record

Perbulan(byte)

OutItem 172 180 30960

OutDetail 28 180 5040

InItem 42 15 630

InDetail 28 15 420

PurchaseOrder 33 15 495

PODetail 54 15 810

ReturBarang 27 3 81

ReturDetail 28 3 84

Hutang 37 15 555

Jumlah : 39.075byte

Perkiraan kebutuhan kapasitas disk untuk

transaksi sebesar 39.075 Byte/bulan

Total disk yang dibutuhkan untuk transaksi selama

1 tahun yaitu 12 bulan x 39.075 = 468.900 Byte =

457,910 Kbyte = 0,447 MByte

Untuk tabel master seperti Employee, Item,

Supplier, SubItem, SubSupplier, Posisi, User

perhitungan akan dilakukan dengan cara berbeda karena

jarang terjadi pertambahan data.

149

Tabel 3.16 Perkiraan Ukuran Record Master

Tabel Size 1 Record

(Byte)

Perkiraan Jumlah

Record Awal

Jumlah Size

Record (Byte)

Employee 173 50 8650

Item 62 2500 155000

Supplier 154 30 4620

User 59 5 295

Posisi 34 10 340

SubItem 129 300 38700

SubSupplier 129 10 1290

Jumlah : 208.895 Byte

Maka perkiraan total kapasitas disk seluruhnya

untuk tahun pertama adalah :

- Tabel Master = 208.895 Byte = 203,999 KB = 0.199

MB

- Transaksi = 0,447 MB/tahun

- Total = 0.199 + 0,447 = 0,646 MB

Bila diperkirakan pertumbuhan data tiap tahunnya

adalah 15 % maka kapasitas disk yang dibutuhkan

dalam 5 tahun mendatang adalah :

150

Tabel 3.17 Kebutuhan Kapasitas Disk dalam 5 tahun

3.2.3.8 Merancang User View

Tahapan ini bertujuan untuk merancang user view yang

teridentifikasi selama pengumpulan kebutuhan dan analisis pada

bagian siklus hidup aplikasi relational database. Pada tahap ini

tidak dilakukan perancangan user view.

3.2.3.9 Perancangan Mekanisme Pengamanan Data

Tahapan ini bertujuan untuk merancang

mekanisme keamanan untuk basis data sesuai spesifikasi dari

pengguna. Adapun mekanisme keamanan yang dirancang untuk

basis data adalah sebagai berikut :

a. Keamanan sistem

Keamanan sistem diterapkan dengan menggunakan

autentikasi pengguna, yaitu dengan menggunakan halaman

Login sebelum masuk ke sistem yang dirancang dalam

Tahun

ke-n

Jumlah disk

tahun ke n-1

Pertumbuhan data

tiap tahun (15%)

Kebutuhan

Total

II 0,646 MB 0,097 MB 0,743 MB

III 0,743 MB 0,111 MB 0,854 MB

IV 0,854 MB 0,128 MB 0,982 MB

V 0,982 MB 0,147 MB 1,129 MB

151

aplikasi. Pada halaman Login, pengguna diminta memasukkan

username dan password. Selain itu, juga diatur agar pengguna

hanya bisa menggunakan fungsi-fungsi tertentu dalam

program sesuai dengan haknya.

b. Keamanan data

Keamanan data ini diterapkan menggunakan autorisasi

pengguna dengan tujuan membatasi hak akses pengguna

terhadap relasi yang ada.

Tabel 3.18 Pengamanan Data

Admin General

Affair

Bagian

Gudang

Employee RUDI RUI R

Item RUDI RUI RUI

Supplier RUDI RUI RUI

User RUDI RU RU

Posisi RUDI RUI R

SubItem RUDI RUI RUI

SubSupplier RUDI RUI RUI

OutItem RUDI RI RI

OutDetail RUDI RI RI

PurchaseOrder RUDI RI RI

Service

Entitas

152

PODetail RUDI RI RI

InItem RUDI RI RI

InDetail RUDI RI RI

Hutang RUDI RI RI

ReturBarang RUDI RI RI

ReturDetail RUDI RI RI

3.2.4 Perancangan Program Aplikasi

Di bagian ini akan dibahas mengenai perancangan aplikasi, di

mana terdapat antara lain struktur menu, STD (State Transition Diagram),

perancangan layar, perancangan laporan dan spesifikasi proses.

3.2.4.1 Struktur Menu

Struktur menu menjelaskan tentang susunan dari menu

yang ada di dalam perancangan aplikasi yang akan digunakan.

153

Gambar 3.22 Struktur Menu User

3.2.4.2 STD

Berikut ini adalah State Transition Diagram yang

merupakan gambaran tentang perubahan kondisi jika aplikasi

dijalankan.

154

Form Menu Utama

Gambar 3.23 STD Menu Utama

Gambar diatas merupakan State Transition Diagram dari

halaman menu utama , setelah menjalankan aplikasi maka

pengguna diharuskan melakukan login terlebih dahulu untuk

mengakses data dan fungsi-fungsi yang ada didalam aplikasi.

Pengguna yang bisa menggunakan aplikasi ini hanya pengguna

yang dibuatkan userID oleh administrator saja.

155

Apabila pengguna gagal login yang disebabkan salah

password atau username, maka akan muncul pesan eror yang

memeberitahukan pengguna aplikasi. Setelah berhasil melakukan

login maka pada layar pengguna akan muncul sebuah window

menu utama yang bila diklik akan muncul sub menu untuk

mengakses fungsi-fungsi yang disediakan oleh aplikasi.

Menu File

Gambar 3.24 STD Menu File

Gambar diatas merupakan State Transition Diagram bila

menu file, dimana sebelumnya pengguna sukses melakukan login

156

dan mengklik menu file yang tersedia pada menu utama dan

memilih sub menu yang tersedia. Pada menu file tersedia 2 sub

menu, yaitu logout dan ubah password. Sub menu logout

digunakan untuk keluar dari menu utama dan fungsi-fungsi

lainnya kembali ke login. Sedangkan sub menu ubah password

digunakan untuk melakukan pergantian password.

Menu Master

Catatan : Operasi untuk setiap sub menu master sama (Employee, Supplier, Item, Jabatan Karyawan,

Jenis Barang dan Jenis Supplier)

Gambar 3.25 STD Menu Master

157


menu master, dimana sebelumnya pengguna sukses melakukan

login dan mengklik menu master yang tersedia pada menu utama

dan memilih sub menu yang tersedia. Menu master memiliki 3

sub menu, yaitu Employee, Item, dan Supplier. Fungsi yang

disediakan ketiga sub menu tersebut digunakan untuk

menampilkan, memasukan dan mengubah data-data yang pada

tabel Employee, Item , dan Supplier didalam database.

Menu Inventory

Catatan : Operasi untuk setiap sub menu inventory sama

(Penerimaan, Pengambilan dan Retur Barang)

Gambar 3.26 STD Menu Inventory

158


menu inventory, dimana sebelumnya pengguna sukses melakukan

login dan mengklik menu inventory yang tersedia pada menu

utama dan memilih sub menu yang tersedia. Menu inventory

memiliki 3 sub menu, yaitu Penerimaan, Pengambilan dan Retur

Barang. Fungsi yang disediakan ketiga sub menu tersebut

digunakan untuk menampilkan dan memasukan data-data yang

pada tabel yang berhubungan dengan fungsi penerimaan ,

pegambilan dan retur barang didalam database.

Menu Transaksi

Gambar 3.27 STD Menu Transaksi

159


menu transaksi, dimana sebelumnya pengguna sukses melakukan

login dan mengklik menu transaksi yang tersedia pada menu

utama dan memilih sub menu yang tersedia. Menu transaksi

memiliki 1 sub menu, yaitu Purchase Order. Fungsi yang

disediakan sub menu tersebut digunakan untuk menampilkan dan

memasukan data-data yang pada tabel PurchaseOrder didalam

database.

Menu Laporan

Catatan : Operasi untuk setiap sub menu Laporan sama (Barang Masuk, Barang Keluar, Stok

Barang dan Hutang)

Gambar 3.28 STD Menu Laporan

160


menu laporan, dimana sebelumnya pengguna sukses melakukan

login dan mengklik menu laporan yang tersedia pada menu utama

dan memilih sub menu yang tersedia. Menu laporan memiliki 3

sub menu, yaitu Barang Masuk, Barang Keluar dan Hutang.

Fungsi yang disediakan sub menu tersebut digunakan untuk

menampilkan informasi mengenai barang masuk , barang keluar

ataupun hutang perusahaan yang nantinya digunakan sebagai

laporan kepada General Affair yang akan diserahkan General

Manajer.

3.2.4.3 Perancangan Layar

Gambar-gambar berikut merupakan rancangan layar yang

akan di bangun dan berfungsi sebagai sarana untuk memasukkan

dan menampilkan data pada aplikasi. Berikut ini adalah gambar

rancangan layar yang telah dibuat :

Gambar 3.29 Rancangan Layar Login

161

Gambar 3.30 Rancangan Layar Menu

Gambar 3.31 Rancangan Layar Ubah Password

162

Gambar 3.32 Rancangan Layar Master Employee

Gambar 3.33 Rancangan Layar Jabatan Karyawan

163

Gambar 3.34 Rancangan Layar Master Item

Gambar 3.35 Rancangan Layar Jenis Barang

164

Gambar 3.36 Rancangan Layar Master Supplier

Gambar 3.37 Rancangan Layar Jenis Supplier

165

Gambar 3.38 Rancangan Layar Inventory Penerimaan

Gambar 3.39 Rancangan Layar Detail Penerimaan Barang

166

Gambar 3.40 Rancangan Layar Tambah Penerimaan Barang

Gambar 3.41 Rancangan Layar Inventory Pengambilan Barang

167

Gambar 3.42 Rancangan Layar Detail Pengambilan Barang

Gambar 3.43 Rancangan Layar Tambah Pengambilan Barang

168

Gambar 3.44 Rancangan Layar Inventory Retur Barang

Gambar 3.45 Rancangan Layar Detail Retur Barang

169

Gambar 3.46 Rancangan Layar Tambah Retur Barang

Gambar 3.47 Rancangan Layar Transaksi Purchase Order

170

Gambar 3.48 Rancangan Layar Detail Purchase Order

Gambar 3.49 Rancangan Layar Tambah Purchase Order

171

Gambar 3.50 Rancangan Layar Laporan Barang Masuk

Gambar 3.51 Rancangan Layar Cetak Laporan Barang Masuk

172

Gambar 3.52 Rancangan Layar Laporan Barang Keluar

Gambar 3.53 Rancangan Layar Cetak Laporan Barang Keluar

173

Gambar 3.54 Rancangan Layar Laporan Stok Barang

Gambar 3.55 Rancangan Layar Cetak Laporan Stok Barang

174

Gambar 3.56 Rancangan Layar Laporan Hutang

Gambar 3.57 Rancangan Layar Cetak Laporan Hutang

bab 3 analisis dan perancangan 3.1 analisisthesis.binus.ac.id/asli/bab3/2011-2-00303-if bab...

Documents