BAB 3 ANALISIS DAN PERANCANGAN

(1)

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.

(2)

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.

(3)

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”.

(4)

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.

(5)

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.

(6)

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.

(7)

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.

(8)

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

(9)

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 :

(10)

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:

(11)

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.

(12)

Gambar 3.2 Flowchart Prosedur Persediaan

(13)

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.

(14)

(15)

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.

(16)

(17)

3.1.6 Data Flow Diagram (DFD)

Berikut ini merupakan gambaran Data Flow Diagram PT. Langgeng Pranamas Sentosa.

(18)

(19)

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.

(20)

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.

(21)

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.

(22)

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

(23)

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.

(24)

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.

(25)

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.

(26)

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…*

(27)

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

(28)

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

(29)

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

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

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

(30)

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

NamaBarang Nama barang Varchar(30) 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

InID Kode penerimaan

barang

(31)

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

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

NamaSupplier Nama supplier Varchar(50) No No

BID Kode barang Char(10) No No

NamaBarang Nama barang Varchar(30) No No

(32)

Unit Satuan barang Varchar(10) No No 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

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

(33)

TanggalRetur Tanggal retur barang

Datetime No No

NamaSupplier Nama supplier Varchar(50) No No

EmID Kode karyawan Char(10) No No

NamaKaryawan Nama karyawan Varchar(50) No No BID Kode barang Char(10) No No

NamaBarang Nama barang Varchar(30) No No

Unit Satuan barang Varchar(10) 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

(34)

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

(35)

4. Tabel OutItem

OutID autonumber

TanggalOut Range Value 0-9, ‘/’, “:” Format dd/mm/yy hh:mm:ss 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 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

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

StokAkhir Range Value 0-9 AlasanPengambilan Range Value a-z, A-Z

5. Tabel InItem

(36)

TanggalIn Range Value 0-9, ‘/’, “:” Format dd/mm/yy hh:mm:ss 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 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]

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

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

StokAkhir Range Value 0-9

6. Tabel PurchaseOrder

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

(37)

[0-9] [0-9] [0-9] [0-9] TanggalPO Range Value 0-9, ‘/’

Format dd/mm/yy

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 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]

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

Harga Range Value 0-9

SubTotal Range Value 0-9

Disc Range Value 0-9

(38)

7. Tabel Hutang

HID autonumber

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]

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 dd/mm/yy hh:mm:ss 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 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]

(39)

NamaKaryawan 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]

Unit Range Value a-z, A-Z, 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

(40)

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

(41)

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

(42)

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.

(43)

2. 3.2.1.8 M Pe m di Purchas PK P Gam Mengh adanya Memvalidasi engguna Tujuan model konse ibutuhkan. Gambar 3 1…1 seOrder 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 nyebabkan 1… PurchaseOrd asi konseptual, al Terhad ah untuk me ng transaks dengan Use 1 InItem PK InID

der dan InIt

tidak ditem dap Tran emastikan b i-transaksi er Transactio Item mukan saksi ahwa yang on

(44)

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.

(45)

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.

(46)

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.

(47)

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.

(48)

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

(49)

2. Item

Gambar 3.17 Menghilangkan Relasi Rekursif (*:*) Item

3. Supplier

Gambar 3.18 Menghilangkan Relasi Rekursif (*:*) Supplier

(50)

4. Menghilangkan tipe relasi kompleks

Dalam pemodelan logikal data lokal, tidak ditemukan adanya tipe relasi kompleks.

5. Menghilangkan atribut multi-valued

Dalam pemodelan logikal data lokal, tidak ditemukan 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)

(51)

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)

(52)

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

(53)

c. Mengidentifikasi Tipe Relasi Biner One to One (1:1) 1. Hubungan antara PurchaseOrder dengan Hutang

(54)

d. Mengidentifikasi Tipe Relasi Biner One to Many (1:*) 1. Hubungan antara Employee dengan OutItem

(55)

3. Hubungan antara Employee dengan ReturBarang

(56)

5. Hubungan antara Supplier dengan PurchaseOrder

(57)

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)

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)

(58)

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)

Employee (EmID)

Foreign Key SupID references Supplier

(SupID)

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

Employee (EmID)

(SupID)

ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur) Primary Key ReID, BID

Foreign Key ReID references ReturBarang (ReID) Foreign Key BID references Item (BID)

(59)

d. Hubungan antara PurchaseOrder dengan Item PurchaseOrder (POID, TanggalPO,

EmID, NamaKaryawan, SupID, NamaSupplier, BID, NamaBarang, Qty, Unit, Harga, SubTotal, Disc, GrandTotal)

Primary Key POID

Employee (EmID)

(SupID)

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

Dalam pemodelan logikal data lokal, tidak ditemukan adanya multi-valued attributes.

(60)

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.

(61)

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.

(62)

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

Dalam relasi tidak terdapat

ketergantungan parsial sehingga relasi telah berada pada kondisi 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

(63)

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)

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)

Stock, Unit, MinimumStock, JBID )

3NF

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF. PurchaseOrder (POID, TanggalPO, EmID, SupID) Employee (EmID,NamaKaryawan, AlamatKaryawan, TelpKaryawan,

(64)

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

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 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)

(65)

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

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

3NF

Dalam relasi terdapat ketergantungan transitif

sehingga perlu dilakukan normalisasi

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

Dalam relasi terdapat ketergantungan transitif sehingga perlu dilakukan normalisasi 3NF. ReturBarang (ReID, TanggalRetur, SupID, EmID)

(66)

TanggalRetur, SupID, NamaSupplier, EmID, NamaKaryawan)

ReturDetail (ReID, BID, NamaBarang, Qty, Unit, AlasanRetur)

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

(67)

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.

(68)

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.

(69)

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)

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

(70)

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

ReturBarang (ReID, TanggalRetur, SupID, EmID) Primary Key ReID

Foreign Key SupID references Supplier(EID) 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

(71)

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.

(72)

(73)

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).

(74)

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 CASCADE ON DELETE NO ACTION,

(75)

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

(76)

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 CASCADE ON DELETE NO ACTION,

);

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,

(77)

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), );

(78)

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 EmID : Fixed length character string, length 10 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,