BAB 3 ANALISIS DAN PERANCANGAN SISTEM

(1)

77

BAB 3

ANALISIS DAN PERANCANGAN SISTEM

3.1. Analisis sistem yang berjalan 3.1.1 Sejarah Perusahaan

AHASS 0596 Dunia Baru merupakan bengkel resmi untuk sepeda motor honda yang bergerak di bidang jasa perawatan/pemeliharaan (H2) dan penjualan spare part (H3). Bengkel ini berada di bawah naungan PT. AHM (Astra Honda M otor) dengan PT. Wahana M akmur Sejati sebagai M ain Dealer di wilayah Jakarta dan Tanggerang. Ahass Dunia Baru didirikan oleh Ibu Irma Iskandar pad Tahun 1987. Pada awal berdirinya, bengkel ini terletak di Jl. Letjen Soeprapto No.40A, Jakarta-Pusat. Namun pada Tahun 2010 bengkel ini dipindahkan ke Jl. Jombang Raya No.7, Tanggerang.

Bengkel ini telah berdiri selama 20 tahun lebih dan memiliki 6 orang mekanik, 1 orang front desk, 1 orang bagian spare part dan 1 orang sebagai kepala bengkel. Seluruh karyawan tersebut telah memiliki standar sertifikasi dari Honda sehingga mereka semua telah terjamin kualitas dan keahlian di bidangnya masing-masing.

(2)

3.1.2 Visi dan Misi

• Visi

Adapun visi dari Ahass Dunia Baru adalah tumbuh dan berkembang sebagai salah satu Bengkel sepeda motor Honda yang terbaik di Indonesia.

• Misi

Adapun misi dari Ahass Dunia Baru adalah memberikan pelayanan servis yang memuaskan bagi semua pengguna sepeda motor Honda, menjadikan sebuah bengkel dengan berbagai macam peralatan modern yang dapat meningkatkan kepercayaan konsumen.

(3)

3.1.3 S truktur Organisasi

Ahass Dunia Baru dipimpin oleh pemilik bengkelnya sendiri dengan dibantu 1 orang kepala bengkel yang bertanggung jawab penuh atas pelaksanaan kegiatan teknis dan non teknis di dalam bengkel. Struktur organisasi dari Ahass Dunia Baru adalah sebagai berikut:

Gambar 3.1 Struktur Organisasi Ahass Dunia Baru

Uraian tugas tentang kepemimpinan bengkel dapat diuraikan sebagai berikut: 1. Kepala Bengkel, bertugas untuk:

1.1 Bertanggung jawab kepada pemilik bengkel atas hasil yang telah diperoleh.

1.2 M engawasi jalannya bengkel baik dari segi manajemen maupun dari segi kualitas mekanik.

(4)

1.3 Terjun langsung ke lapangan ketika terjadi ketidakpuasan dari konsumen.

2. Mekanik, bertugas untuk:

1.1 M erawat dan memperbaiki sepeda motor konsumen yang masuk ke bengkel.

1.2 M emberikan kualitas terbaik dalam melakukan service motor. 1.3 M emberikan penjelasan kepada konsumen tentang

kerusakan-kerusakan yang terjadi pada sepeda motor konsumen. 3. Bagian S pare Part, bertugas untuk:

1.1 M engawasi barang yang masuk dan yang keluar.

1.2 M embuat laporan pembelian, laporan persediaan barang, dan melaporkannya kepada kepala mekanik.

1.3 M engawasi sisa barang yang ada dan segera melakukan penyetokan sehingga tidak terjadi kekosongan barang.

4. Front Desk, bertugas untuk:

1.1 M enyambut konsumen yang datang ke bengkel dan mencatat WO(Work Order).

1.2 M encatat keluhan-keluhan yang ada pada sepeda motor konsumen.

1.3 M emberikan informasi kepada konsumen mengenai harga servis dan harga barang.

(5)

1.5 M encatat data-data pelanggan.

5. Pemilik Bengkel, sebagai penanam modal sekaligus pimpinan dimana memegang kekuasaan penuh, wewenang dan tanggung jawab atas bengkel tersebut.

3.1.4 Prosedur yang Sedang Berjalan 3.1.4.a Sistem Pembelian

Prosedur pembelian barang yang berlaku di Ahass Dunia Baru adalah sebagai berikut:

1. Setelah mendapat persetujuan dari Pemilik Bengkel, bagian spare part membuat laporan persediaan stok barang.

2. Laporan tersebut kemudian di cocokan dengan jumlah barang yang ada di gudang.

3. Kemudian dibuat laporan persediaan stok barang yang sudah di update.

4. Setelah laporan persediaan stok barang yang sudah diupdate selesai di buat, bagian spare part akan mencocokan laporan dengan barang yang tersedia di gudang dan mengupdate stok barang untuk mengetahui barang mana yang sudah habis atau di bawah stok minimum dan harus dipesan.

(6)

5. Jika stok barang masih mencukupi maka sistem diaggap selesai, namun apabila ada kekurangan stok barang maka bagian spare part akan membuat Surat Purchase Order.

6. Surat Purchase Order tersebut dibuat rangkap dua. Yang pertama dikirimkan ke supplier sebagai bukti pemesanan barang. Yang kedua disimpan sebagai arsip untuk dicocokan dengan Faktur Pembelian.

(7)

(8)

3.1.4.b Sistem Persediaan

Prosedur sistem persediaan barang yang berlaku di Ahass Dunia Baru adalah sebagai berikut:

1. Setelah supplier menerima surat purchase order, maka akan dilakukan pengiriman barang sesuai dengan pesanan ke bagian front desk.

2. Setelah barang diterima, bagian spare part akan memeriksa kuantitas dan kualitas barang sesuai purchase order.

3. Kemudian dilakukan pengecekan secara fisik untuk mengetahui apakah ada barang yang rusak atau kurang..

4. Setelah semua barang yang diterima sesuai dengan surat purchase order, maka barang tersebut akan diterima dan disimpan ke gudang.

5. Pembayaran kepada pemasok akan dilakukan 1 bulan setelah barang diterima.

(9)

(10)

3.1.4.c Sistem Penjualan

Prosedur sistem penjualan barang yang berlaku di Ahass Dunia Baru adalah sebagai berikut:

1. Sistem penjualan dimulai dengan pemesanan barang(sales order) oleh konsumen ke bagian front desk.

2. Setelah sales order diterima, bagian front desk akan melaporkan pemesanan barang kepada bagian spare part untuk dilakukan pengecekan apakah barang yang dipesan tersedia di gudang atau tidak.

3. Kemudian bagian spare part akan melakukan pengecekan apakah barang yang dipesan tersedia di gudang atau tidak.

4. Jika barang tidak tersedia di gudang maka transaksi dianggap selesai. Namun apabila barang tersedia di gudang, bagian spare part akan melaporkan ke bagian front desk untuk diteruskan ke konsumen.

5. Bagian front desk akan membuatkan faktur penjualan rangkap 2(dua). Lembar pertama untuk konsumen sebagai bukti bahwa barang tersebut telah dipesan sedangkan lembar yang kedua sebagai arsip bengkel untuk menghitung jumlah barang yang telah keluar per harinya.

6. Setelah faktur diserahkan ke konsumen, maka akan dilakukan transaksi pembayaran oleh konsumen ke bagian front desk.

(11)

7. Jika pembayarannya sesuai maka barang akan diserahkan ke konsumen.

(12)

Sistem Penjualan

Gudang Bagian Front Desk Bagian Spare Part

Konsumen

Mul ai

Laporan

Pemesanan Cek

Selesai

Faktur Penj ualan

Selesai tida k ada ada Laporan Barang tersedia Laporan Barang tersedia Faktur Penjualan Pembayaran OK ya Sale s Ord er Menerima Sales Orde r Konsumen Me mbuat Laporan Pemesanan Barang Pembayaran Me mbuat Faktur pe njualan Penyerahan barang Menerima barang

(13)

3.1.4.d Sistem Pembayaran

Prosedur Sistem Pembayaran ke Supplier yang berlaku di Ahass Dunia Baru adalah sebagai berikut:

1. Pembayaran dilakukan 1 bulan setelah barang dikirim menggunakan rekening giro.

2. Bagian front desk akan melakukan pengecekan terhadap purchase order yang sudah jatuh tempo.

3. Jika ditemukan purchase order yang sudah jatuh tempo, maka akan dilakukan transaksi pembayaran ke supplier.

4. Bukti pembayaran dan giro dibuat rangkap 2(dua). Lembar pertama diberikan kepada supplier sebagai media pembayaran sedangkan lembar yang kedua disimpan sebagai bukti pembayaran.

(14)

(15)

3.1.5 Pemodelan Proses 3.1.5.a Diagram Konteks

Ini merupakan sistem yang ada dalam Ahass Dunia Baru dari pemesanan barang ke supplier yaitu PT.Wahana M akmur Sejati sampai kepada penjualan kepada konsumen. Setelah melakukan pengecekan terhadap stok barang di gudang, jika terjadi kekosongan barang maka akan dilakukan pemesanan barang kepada PT.Wahana M akmur Sejati. Selambat-lambatnya barang akan dikirmkan dalam jangka waktu 1 minggu setelah proses pemesanan. Dalam sistem penjualan barang, barang yang dipesanan oleh konsumen akan langsung diberikan kepada konsumen dengan pembayaran secara tunai. Kedua transaksi tersebut, baik pembelian dan penjulan menggunakan faktur sebagai bukti terjadinya transaksi.

(16)

SISTEM BASI S DATA PADA AHASS DUNI A

BARU Konsumen Supplier Manajemen Sales Order Pengiriman Barang Purchase order

Fakt ur Penjualan Faktur Pembelian

Penyerahan Barang La po ra n-la po ra n P e rm in ta an La po ra n Retur Pembelian Ret ur Penjualan

(17)

3.1.5.b DFD Level Nol

Jika terjadi Pembelian barang maka input data barang-barang yang diterima akan dimasukkan ke dalam daftar persediaan stok barang. Jika terdapat penerimaan barang maka persediaan barang bertambah. Jika terjadi penjualan barang maka persediaan barang akan berkurang.

(18)

(19)

3.1.6 Analisis Kebutuhan Informasi

Dalam pelaksanaan prpses bisnis pada Ahass Dunia Baru diperlukan informasi sebagai berikut:

Tabel 3.1 Tabel Kebutuhan Informasi Pengguna Pemilik Bengkel Kepala Bengkel Bagian Spare Part Bagian Front Desk Infromasi Laporan Pembelian X X X Laporan Penjualan X X X Laporan Persediaan Stok Barang X X X X Daftar Pegawai X X Daftar Supplier X X X Daftar Konsumen X X X

Dalam pelaksanaan bengkel terdapat berbagai dokumen yang dikeluarkan dan disimpan. Dokumen-dokumen tersebut dapat diklasifikasikan lebih rinci sehingga sesuai dengan bagian-bagiannya.

(20)

Tabel 3.2 Tabel Representasi Analisis Kebutuhan Informasi No. Nama Entity Deskripsi

1. Laporan Pembelian Berisikan data-data mengenai pembelian barang yang dipesan dari Supplier.

2. Laporan Penjualan Berisikan data-data mengenai penjualan spare part yang dilakukan oleh Ahass Dunia Baru. 3. Laporan Persediaan

Stok Barang

Berisikan data-data mengenai barang-barang yang ada di gudang dan jumlah persediaanya. 4. Konsumen Berisikan data-data pribadi dari konsumen yang

melakukan pemesanan barang.

5. Supplier Berisikan data-data mengenai supplier yang men-supply barang.

3.1.7 Permasalahan yang dihadapi

Setelah melakukan wawancara dan analisis terhadap transaksi pembelian, penjualan, dan persediaan ditemukan masalah-masalah sebagai berikut:

1. Sulitnya perusahaan untuk mengetahui jumlah persediaan yang ada di gudang secara pasti.

2. Sulit dan lamanya pencatatan data transaksi ke dalam dan ke luar karena perusahaan masih mencatat data transaksi secara manual menggunakan nota penjualan dan pembelian.

3. M embutuhkan waktu yang cukup lama dalam penghitungan sisa stok barang yang tersedia di gudang.

4. Sering terjadi kesalahan penghitungan antara jumlah stok barang di buku stok dengan jumlah barang yang ada di gudang.

(21)

5. Sering kehabisan stok barang karena barang yang ada di gudang sudah habis dan terlambat untuk di pesan ke M ain Dealer.

3.1.8 Alternatif Pemecahan Masalah

Berdasarkan permasalahan yang telah disebutkan di atas, maka kami membuat suatu perancangan sistem basis data menggunakan SQL server 2005. Basis data yang dibuat ini bertujuan untuk mempercepat waktu pencatatan setelah terjadi transaksi pembelian maupun penjualan sehingga jumlah stok barang yang ada di gudang dapat diketahui dengan pasti jumlah persediaannya.

Sistem basis data tersebut kemudian di aplikasikan ke dalam sebuah program desktop. Program tersebut kami buat menggunakan Visual Basic 2008 Express Studio. Aplikasi ini diharapkan dapat membantu pembuatan laporan pembelian dan penjualan yang akurat karena dihitung secara komputerisasi.

(22)

3.2 Perancangan Basis Data

Perancangan basis data dilakukan berdasarkan kebutuhan informasi yang telah diidentifikasi pada AHASS Dunia Baru,dibagi dalam tiga tahapan yaitu:

a. Perancangan Basis Data Konseptual(Conceptual database design) b. Perancangan Basis Data Logikal (Logikal Databse design)

c. Perancangan Basis Data Fisikal (Physical Database Design)

3.2.1 Perancangan Basis Data Konseptual

Perancangan basis data konseptual merupakan suatu proses pembuatan sebuah model informasi yang digunakan pada perusahaan,bebas dari semua pertimbangan fisik.Adapun langkah-langkah dalam perancangan dalam pembuatan perancangan basis data konseptual adalah sebagai berikut:

Tahap 1 membangun model data konseptual 1. mengidentifikasi tipe entity

2. mengidentifikasi tipe relationship

3. mengidentifikasi dan mengasosiasikan atribut suatu entity 4. menemukan domain atribut

5. menentukan candidate key dan primary key

6. mempertimbangkan konsep enchaned modeling(langkah optional) 7. memeriksa model dari adanya redudansi

8. mengvalidasikan model konseptual local dengan transaksi user 9. mengreview model data konseptual dengan user

(23)

3.2.1.a Mengidentifikasi Tipe Entity

Entity-entity yang menjadi kebutuhan dari AHASS Dunia Baru setelah melalui proses analisis sistem adalah sebagai berikut:

Tabel 3.3 identifikasi tipe Entity

Entity Name Descpription Aliases Occurance Pegawai M erupakan entity

yang berisi informasi tentang pegawai yang berkerja pada AHASS Dunia Baru

karyawan Setiap pegawai

dapat menangani nol atau banyak transaksi

penjualan,pembelian dan cek stok

Setiap pegawai berkerja pada bagian tertentu

Bagian Berisi tentang

informasi bagian pegawai pada AHASS Dunia Baru

Departement Setiap bagian memiliki satu atau banyak pegawai

konsumen M erupakan entity yang berisi informasi tentang konsumen yang berbelanja di AHASS Dunia BAru

konsumen Setiap konsumen

yang dating mempunyai kode pegawai sebgaia tanda pengenal seberapa sering konsumen datang untuk membeli barang dan menggunakan service.

Barang M erupakan entity

yang berisi barang yang dijual oleh AHASS Dunia Baru

Produk Setiap barang dapat dimiliki oleh banyak penjualan,pembelian dan cek stok

Cek stok M erupakan entity

yang berisi pengecekan stok

Pengecekan stok Pengecekan atok atau jumlah barang yang tersedia di

(24)

pada AHASS Dunia Baru

gudang yang dilakukan oleh pegawai

Supplier M erupakan entity

yang memuat informasi tentang supplier pada AHASS Dunia Baru

supplier Supplier menerima

purchase order dan meyediakan barang sesuai pesanan

Sales order M erupkan entity

yang berisi informasi

penjualan pada AHASS Dunia Baru

Penjualan barang Setiap penjualan disebabkan oleh konsumen atau pelanggan yang diatur oleh pegawai Purchase order M erupakan Entity

yang berisi informasi

pembelian barang pada AHASS Dunia Baru pada supplier

Pembelian barang Setiap pembelian dilakukan oleh pegawai untuk memesan barang pada supplier

Pembayaran M erupakan entity yang berisi informasi

pembayaran pada AHASS Dunia Baru

pembayaran Pembayaran yang dilakukan pegawai kepada supplier untuk melunasi biaya pembelian barang

3.2.1.b Mengidentifikasi Tipe Relationship

Tujuan dari tahap inilah adalah untuk menentukan hubungan antara entity-entity yang ada.Berikut ini adalah Entity Relationship (ER) diagram konseptual yang memuat nama entity,multiplicity berserta relationship antar entiry.

(25)

Bagian Pegawai Sales_Order Purchase_Order Konsumen Pembayar an Supplier Cek_Stok Barang Memiliki Mel akukan Menangani

Mel akukan Menerima

Mel akukan Melakuka n Memesan Memesan Mel akukan 1.. * 1. .1 1.. * 1..* 1..* 1. .1 1.. * Menangani 1.. 1 1.. * 1.. * 1. .* 1. .1 1.. 1 1.. * 1. .1 1..1 1.. 1 1.. * 1. .1 1.. * 1. .1 1.. * Menyesuaikan 1.. * 1. .*

(26)

Berikut adalah tabel multiplicity dari tipe relationship antar entity : Tabel 3.4 M ultiplicity Tipe Relationship

Entity Name M ultiplicity Relationship Entity Name M ultiplicity Pegawai 1.1 1.1 1.1 1.1 M enangani melakukan M elakukan melakukan Sales_order Cek_stok Purchase_order pembayaran 1.* 1.* 1.* 1.*

Bagian 1.1 M emiliki pegawai 1.*

Cek_stok 1.* menyesuaikan barang 1.*

supplier 1.1 M enangani Pembelian 1.*

Sales_order 1.* M elibatkan Barang 1.* Konsumen 1.* 1.1 M emesan M elakukan Barang Pembayaran 1.* 1.*

3.2.1.c Mengidentifikasi dan Mengasosiasikan Atribut suatu Entity

Tujuan dari tahap ini adalah menghubungkan atribut dengan entity ataupun relationship yang sesuai. Berikut ini merupakan tabel setiap entity dengan atribut masing-masing.

(27)

Tabel 3.5 Dokumen Atribut dari Entity

Entity Name Attribute Description

data type&

length NULL Multi Valued Pegawai Kode_pegawai Kode pegawai char (5) NO NO

nama_pegawai nama pegawai varchar (30) NO NO

alamat_pegawai alamat pegawai varchar (100) NO NO telepon_pegawai telepon pegawai varchar (15) NO NO

password password varchar (10) NO NO

Bagian Kode_Bagian Kode Bagian char (4) NO NO

Nama_Bagian Nama Bagian varchar (30) NO NO

Barang Kode_barang Kode barang char (6) NO NO

nama_barang nama barang varchar (30) NO NO

harga_jual harga jual numeric 10,2 NO NO

harga_beli harga beli numeric 10,2 NO NO

jumlah_barang jumlah barang integer NO NO

minimal_stok minimal stok integer NO NO

Supplier Kode_supplier Kode supplier char (6) NO NO Nama_supplier Nama supplier varchar (30) NO NO alamat_supplier alamat supplier varchar (100) NO NO telepon_supplier telepon supplier varchar (15) NO NO Konsumen Kode_Konsumen Kode Konsumen char(5) NO NO

(28)

Nama_Konsumen Nama Konsumen varchar (30) NO NO Alamat_Konsumen Alamat Konsumen varchar (100) NO NO Telepon_Konsumen Telepon Konsumen varchar (15) NO NO cek stok kode_cek_stok Kode cek stok char (6) NO NO

tgl_cek_stok tanggal cek stok datetime NO NO

jumlah_stok jumlah stok integer NO NO

harga_beli harga beli numeric 10,2 NO NO

sales_order no_faktur no faktur char (6) NO NO

tgl_faktur tgl faktur datetime NO NO

purchase_order No_PO No PO char (6) NO NO

tgl_PO tgl PO datetime NO NO

pembayaran no_Giro No Giro char (6) NO NO

tgl_Giro Tanggal Giro datetime NO NO

total_pembayaran Total pembayaran numeric 10,2 NO NO

3.2.1.d Menentukan Domain Atribut

Tujuan tahap ini adalah untuk menentukan domain dari suatu atribut yang terdapat pada model data konseptual.Domain atribut adalah sekumpulan nilai yang diperkenankan untuk satu atau lebih atribut.

(29)

Tabel 3.6 Dokumen Domain Atribut

Entity Name Attribute Domain attribut

Kode pegawai Kode_pegawai Char(5) [K][P][0-9][0-9][0-9]

Nama pegawai Nama_pegawai Varchar (30)

Telepon pegawai Telepon_pegawai Varchar (15)

Alamat pegawai Alamat_pegawai Varchar (100)

Password Password Varchar (10)

Kode bagian Kode_bagian Char(4) [K][B][0-9][0-9] Nama bagian Nama_bagian Varchar (30)

Kode konsumen Kode_konsumen Varchar(5) [K][S]9] [0-9] [0-[0-9]

Nama konsumen Nama_konsumen varchar (30) Alamat konsumen Alamat_konsumen varchar (100) Telepon konsumen Telepon_konsumen varchar (15)

Kode barang Kode_barang Char(6) [B][R][0-9][0-9][0-9][0-9]

Nama barang Nama_barang Varchar (30)

Harga jual Harga_jual Numeric (10,2)

Jumlah barang Jumlah_barang Integer

(30)

[F][P][0-9][0-9][0-9][0-9]

Tanggal faktur Tgl_faktur Datetime Total penjualan Total_penjualan Numeric (10,2)

Nomor cek stok No_cek_stok Char(6) [C][S][0-9][0-9][0-9][0-9]

Tanggal cek stok Tgl_cek_stok Datetime Kode supplier Kode_supplier Char(6)

[S][P][0-9][0-9][0-9][0-9]

Nama supplier Nama_supplier Varchar (30)

Alamat supplier Alamat_supplier Varchar(100) Telepon supplier Telepon_supplier Varchar (15) Nomor Purchase order No_PO Char(6)

[P][O][0-9][0-9][0-9][0-9] Tanggal Purchase order Tgl_PO Datetime Total pembelian Total pembelian Numeric(10,2)

No giro No_giro Char(6)

[P][P][0-9][0-9][0-9][0-9] Tanggal pembayaran Tgl_giro Datetime Total pembayaran Total_pembayaran Numeric (10,2)

(31)

3.2.1.e Menentukan Atribut Candidate key dan primary key

Tujuan dari tahap ini adalah menentukan candidate key dan primary key untuk setiap entiry yang ada.

Tabel 3.7 Dokumen Atribut Candidate Key dan Primary Key dari Setiap Entity Entity Name Candidate key Primary key

Pegawai Kode pegawai

Telepon pegawai

Kode pegawai

Bagian Kode Bagian

Nama bagian

Kode bagian

Konsumen Kode_konsumen Telepon konsumen

Kode konsumen

Barang Kode Barang

Nama barang

Kode barang

Cek stok No.cek stok No cek stok

Supplier Kode supplier

Telepon supplier

Kode supplier

Purchase order No PO No PO

Sales order No faktur No penjualan

pembayaran No Giro No Giro

berikut ini adalah gambar entity relationship Diagram Konseptual yang dilengkaspi dengan primary key:

(32)

Bagian Kode_Bagian Pegawai Kode_Pegawai Sales_Order No_Faktur Purchase_Order No_PO Konsumen Kode_Konsumen Pembayar an No_Giro Supplier Kode_Supp Cek_Stok No_Cek_Stok Barang Kode_Barang Memiliki Melakukan Menangani

Mel akukan Menerima

Mel akukan Me lakukan Memesan Memesan Mel akukan 1.. * 1. .1 1.. * 1..* 1..* 1. .1 1.. * Menangani 1.. 1 1.. * 1.. * 1. .* 1. .1 1.. 1 1.. * 1. .1 1..1 1.. 1 1.. * 1. .1 1.. * 1. .1 1.. * Menyesuaikan 1.. * 1. .*

Gambar 3.9 Entity relationship Diagram Konseptual dengan primary key 3.2.1.f Mempertimbangkan Konsep Enchaned Modeling(Langkah Optional)

Setelah diperhatikan dari tahap ini dan telah dipertimbangkan,maka pada perancangan konseptual tidak menggunakan konsep pemodelan enchaned.

(33)

3.2.1.g Memeriksa Model Dari Redudansi

Setelah ditelti tidak ada adanya bentuk redundansi atau pemanggilan kembali. 3.2.1.h Memvalidasikan Model Konseptual Lokal Dengan Transaksi User

Tujuan dari tahap ini adalah untuk menyakinkan bahwa model data konseptual yang dibuat mendukung transaksi user.

Adapun transaksi-transaksi yang diperlukan adalah sebagai berikut: 1. M emasukkan data pegawai

2. M emasukkan data barang 3. M emasukkan data sales order 4. M emasukkan data stok 5. memasukkan data supplier 6. memasukkan data purchase order 7. memasukkan data sales order 8. memasukkan data pembayaran

9. melakukan update/delete data pegawai 10.melakukan update/delete data barang 11.melakukan update/delete data konsumen 12.melakukan update/delete data sales order 13.melakukan update/delete data cek stok 14.melakukan update/delete data supplier 15.melakukan update/delete data purchase order 16.melakukan update/delete data pembayaran

(34)

17.menampilkan data pegawai

18.mencari data pegawai berdasarkan nama pegawai 19.menampilkan data barang

20.mencari data barang berdasarkan nama barang 21.menampilkan data sales order

22.mencari data sales order berdasarkan nomor faktur 23.menampilakn data cek stok

24.mencari data cek stok berdasarkan nomor cek stok 25.mencari data cek stok berdasarkan tanggal penyesuaian 26.menampilkan data supplier

27.mencari data supplier berdasarkan nama supplier 28.menampilkan data purchase order

29.M encari data purchase order berdasarkan kode purchase order 30.menampilkan data pembayaran

(35)

3.2.1.i Mereview Data Konseptual User

Setelah meninjau ulang model data konseptual dengan user maka dapat disimpulkan bahwa model data konseptual yang dibuat sudah sesuai dengan kebutuhan user.

3.2.2 Perancangan Basis Data Logikal

Perancangan basis data logikal merupakan suaut proses pembuatan sebuah model data yang digunakan dalam duaut perusahaan berdasarkan model data yang spesifik tetapi tidak tergantung pada DBM S dan pertimbangan fisik lainnya.M odel data logikal merupakan sumber informasi perancangan tahap fisikal.Adapun langkah-langkahnya yaitu :

Tahap 2 M embangun dan memvalidasi model data logikal 1. menentukan relasi untuk model data logikal

2. mengvalidasi relasi dengan menggunakan normalisasi 3. mengvalidasi relasi terhadap transaksi user

4. menentukan integrity constraint

5. menreview model data logikal dengan user

6. menggabungkan model-model data logikal menjadi model global 7. memeriksa pertumbuhan di masa depan

(36)

3.2.2.a Menentukan Relasi Untuk Model Data Logikal

Tujuan dari tahap ini adalah membuat relasi dari model data logikal untuk menampilkan kembali entity,relationship dan atribut yang telah didefinisikan.

1.) Strong Entity type

Pegawai(kode_pegawai,nama_pegawai,alamat_pegawai,telepon_pegawai, password,kode_bagian)

primary key : kode_pegawai

Bagian(kode_bagian,nama_bagian) primary key : Kode_bagian

Konsumen(kode_konsumen,nama_konsumen,alamat_konsumen,telp_konsum en)

primary key : kode_konsumen

Barang(kode_barang,nama_barang,harga_jual,jumlah_stok) primary key : Kode_barang

sales order(no_faktur,tgl_faktur,total_penjualan) primary key : no_faktur

(37)

cek stok(no_cek_stok,tgl_cek_stok,jumlah_stok) primary key : no_cek_stok

supplier(kode_supp,nama_supp,alamat_supp,telepon_supp) primary key : kode_supp

purchase order(Kode_PO,tgl_PO) primary key : kode_PO

pembayaran(no_giro,tgl_giro,total_pembayaran) primary key : no_giro

2.) Weak entity type

sales_order_detail(kode_barang,kuantitas) primary key: none

cek_stok_detail(Kode_barang,jumlah_stok) primary key : none

purchase_order_detail(kode_barang,nama_barang,kuantitas,no_PO) primary key : none

(38)

3.) one to many(1.*) binary relationship

Untuk setiap hubungan one to many,entity pada one side dalam relasi menjasi parent sedangkan untuk entity pada many side menjadi child.

Pegawai (kode_pegawai, nama_pegawai, alamat_pegawai, telp_pegawai,

kode_bagian)

primary key kode_pegawai foreign key kode_bagian

purchase_order(No_PO, Tgl_PO, kode_supp, nama_pegawai) primary key No_PO

foreign key kode_supp, kode_pegawai

post pegawai ke purchase_order Pegawai (kode_pegawai, nama_pegawai,

alamat_pegawai, telp_pegawai, kode_bagian)

Sales_order(No_Faktur, tgl_faktur, kode_pegawai, nama_pegawai) primary key No_Faktur

foreign key kode_pegawai, kode_konsumen

(39)

kode_bagian)

bagian (kode_bagian) primary key kode_bagian post pegawai ke bagian

kode_bagian)

Pembayaran(No_Giro, tgl_giro, kode_supp, kode_konsumen, no_faktur, no_PO)

primary key No_Giro foreign key kode_supp post pegawai ke pembayaran

kode_bagian)

Cek_Stok (no_cek_stok, tgl_cek_stok, kode_pegawai, kode_supp)

primary key no_cek_stok foreign key kode_barang post pegawai ke cek_stok

(40)

4.) one to one binary relationship

setelah melakukan pengecekan tidak ada one to one binary relationship pada table diagram.

5.) one to one recursive relationship

setelah melakukan pengecekan tidak ada one to one recursive relationship pada table diagram.

Pembayaran(No_Giro, tgl_giro,

kode_supp, kode_konsumen, no_faktur, no_PO)

primary key No_Giro foreign key kode_supp

Supplier(kode_supp, nama_supp, alamat_supp, email_supp,

no_cek_stok)

primary key kode_supp post pembayaran ke supplier

Supplier(kode_supp, nama_supp, alamat_supp, email_supp, no_cek_stok) primary key kode_supp

foreign key kode_supp, kode_pegawai

(41)

6.) superclass/subclass relation type

setelah dilakukan pengecekan tidak ada superclass/subclass pada model data konseptual.

7.) many to many binary relationship types

Untuk tiap hubungan many to many dibuat suatu relasi yang mempertasikan hubungan.antar entiry dan memasukkan seluruh atribut yang merupakan bagian dengan relasi .Primary key disalinkan pada relasi baru juga bertindak sebagai foreign key.

Barang(Kode_Barang, nama_barang, harga_jual, harga_beli, jumlah_stok, minimal_stok)

Primary key kode_barang

Sales_order(No_Faktur, tgl_faktur, kode_pegawai, nama_pegawai) primary key No_Faktur

post barang ke sales_order

Sales_Order_Detail(No_Faktur, Kode_Barang, Kuantitas) Primary key no_faktur

(42)

Primary key kode_barang

post barang ke purchase_order

Purchase_Order_Detail(No_PO, Total_Pembelian, Kode_Barang) Primary key No_PO

(43)

8.) complex relationship types

Pada ERD tidak terdapat relasi kompleks 9.) M ulti-valued atributs

Untuk semua atribut multi valued dibuat sebuah relasi baru untuk mempretasikan multi-valued dan masukkan primary key entitas asal pada relasi baru untuk bertindak sebgaia foreign key.

Cek_Stok (no_cek_stok, tgl_cek_stok, kode_pegawai, kode_supp)

primary key no_cek_stok foreign key kode_barang

Primary key kode_barang post cek_stok ke barang

Cek_Stok_Detail(No_Cek_Stok, Jumlah_Stok, Kode_Barang) Primary key No_Cek_Stok

(44)

3.2.2.b Mengvalidasi Relasi Dengan Menggunakan Normalisasi Normalisasi pembelian/purchase order

UNF Purchase_order{@no_Po,tgl_PO,kode_pegawai,nama_pegawai,kode_supplier,nama_ supplier,kode_barang, nama_barang,harga_beli,kuantitas} 1NF Purchase_order{@no_Po,tgl_PO,kode_pegawai,nama_pegawai,kode_supplier,nama_ supplier,kode_barang }

Purchase_order_detail{@ no_PO,kode_barang, nama_barang,harga_beli,kuantitas} 2NF Purchase_order{@no_Po,tgl_PO,kode_pegawai,nama_pegawai,kode_supplier,nama_ supplier,kode_barang } Purchase_order_detail{@ no_PO,kode_barang,kuantitas} Barang{@kode_barang, nama_barang,harga_beli} 3NF Purchase_order{@no_Po,tgl_PO,kode_pegawai,kode_supplier,kode_barang } Purchase_order_detail{@no_PO kode_barang,kuantitas} Barang{@kode_barang, nama_barang,harga_beli} Pegawai{@kode_pegawai,nama_pegawai,alamat_pegawai,telp_pegawai,password} Supplier{@kode_supplier,nama_supplier,alamat_supplier,telp_supplier}

Normalisasi Persediaan/cek stok UNF

(45)

Cek_stok{@no_cek_stok,tgl_cek_stok,kode_pegawai,nama_pegawai,kode_barang, nama_barang,jumlah_stok} 1NF Cek_stok{@no_cek_stok,tgl_cek_stok,kode_pegawai,nama_pegawai,kode_barang, nama_barang,jumlah_stok} cek_stok_detail(@no_cek_stok,kode_barang,nama_barang,jumlah_stok) 2NF Cek_stok{@no_cek_stok,tgl_cek_stok,kode_pegawai,kode_barang} cek_stok_detail{@no_cek_stok,kode_barang,jumlah_stok} Barang(@kode_barang,nama_barang} 3NF Cek_stok{@no_cek_stok,tgl_cek_stok,kode_pegawai,kode_barang,} cek_stok_detail{@no_cek_stok,kode_barang,jumlah_stok} Barang(@kode_barang,nama_barang} Pegawai{@kode_pegawai,nama_pegawai,alamat_pegawai,telp_pegawai,password}

Normalisasi penjualan/sales order UNF

Sales_order{@no_faktur,tgl_faktur,kode_pegawai,nama_pegawai,kode_konsumen,n ama_konsumen,kode_barang, nama_barang,harga_jual,kuantitas}

(46)

Sales_order{@no_faktur,tgl_faktur,kode_pegawai,nama_pegawai,kode_konsumen,n ama_konsumen,kode_barang} Sales_order_detail{@no_faktur,kode_barang, nama_barang,harga_jual,kuantitas} 2NF Sales_order{@no_faktur,tgl_faktur,kode_pegawai,nama_pegawai,kode_konsumen,n ama_konsumen,kode_barang} Sales_order_detail{@no_faktur,kode_barang,kuantitas} Barang{@kode_barang, nama_barang,harga_jual} 3NF Sales_order{@no_faktur,tgl_faktur,kode_pegawai,kode_konsumen,kode_barang} Sales_order_detail{@no_faktur,kode_barang,kuantitas} MsBarang{@kode_barang, nama_barang,harga_jual} Pegawai{@kode_pegawai,nama_pegawai,alamat_pegawai,telp_pegawai,password} konsumen{@kode_konsumen,nama_konsumen,alamat_konsumen,telp_konsumen}

3.2.2.c Mengvalidasi Relasi Terhadap Transaksi User

Transaksi ini dilakukan dengan cara memerisa kembali semua transaksi user yang telah didefinisikan pada tahap konseptual terhadap relasi yang ada.Seetelah meninjau ulang model data logika local dengan user maka dapat disimpulkan bahwa model data logikal sudah mendukung transaksi-transaksi yang dibutuhkan user. 3.2.2.d Menentukan integrity constraint

(47)

Tujuan pada tahap ini adalah untuk memeriksa interigrity constraint yang dipresentasikan pada mode data logikal.

1. Required data

beberapa attribute harus mempunya nilai yang valid,dengan kata lain atribut-atribut yang ada tidak mempunyai nilai null.

2. Attribute domain constraints

setiap atribut memliki domain yaitu kumpulan dari nilai yang sah. 3. Multiplcity

menampilkan constraint yang ditempatkan pada relasi antar data dalam database

4. Entity integrity

primary key dari suatu entity tidak boleh mempunyai nilai null 5. Refential integrity

apabila suatu table memiliki foreign key yang mengandung suatu nilai maka nilai menunjuk pada barisyang ada relasi parent.Berikut adalah refential integrity constraint pada model data logika:

(48)

Tabel 3.8 Tabel Referential Integrity Constraints Barang(kode_barang,nama_barang,harga_jual,jumlah_stok,minimal_stok) Primary key: kode_barang

Konsumen(Kode_konsumen,nama_konsumen,alamat_konsumen,telepon_konsumen) Primary key: kode_konsumen

Pegawai(kode_pegawai,nama_pegawai,alamat_pegawai,telepon_pegawai,password,k ode_bagian)

Primary key: kode_pegawai

Foreign key:kode_bagian references bagian(kode_bagian) ON UPDATE CASCADE ON DELETE NO ACTION Bagian(Kode_bagian,namaBagian)

Primary key:kode_bagian

supplier(kode_supp,nama_supp,alamat_supp,telepon_supp) primary key:kode_supp

sales_order(no_faktur,tgl_faktur,kuantitas,kode pegawai,kode konsumen) primary key:no_faktur

foreign key:kode_pegawai references pegawai(kode_pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

kode_konsumen references konsumen(kode_konsumen) ON UPDATE CASCADE ON DELETE NO ACTION sales_order_detail(no_faktur,kode_barang,kuantitas) primary key:no_faktur,kode_barang

foreign key:no_faktur refrences sales_order(no_faktur) ON UPDATE CASCADE ON DELETE NO ACTION kode _barang references barang(kode_barang)

(49)

purchase_order(no_PO,tgl_PO,kode_pegawai,kode_supplier) primary key:no_PO

foreign key: kode_pegawai references pegawai(kode_pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

kode_supp references supp(kode_supp)

ON UPDATE CASCADE ON DELETE NO ACTION Purchase_order_detail(no_PO,kode_barang,tgl_PO,kuantitas) Primary key:no_PO,kode_barang

Foreign key: no_PO refrences purchase_order(no_PO) ON UPDATE CASCADE ON DELETE NO ACTION kode _barang references barang(kode_barang)

ON UPDATE CASCADE ON DELETE NO ACTION

Pembayaran(no_giro,tgl_giro,no_PO,kode pegawai,kode_supp) Primary key: no_giro

Foreign key: no_PO refrences purchase_order(no_PO) ON UPDATE CASCADE ON DELETE NO ACTION kode_pegawai references pegawai(kode_pegawai) ON UPDATE CASCADE ON DELETE NO ACTION kode_supp references supp(kode_supp)

cek-stok(@no_cek_stok,tgl_cek_stok,kode_pegawai) primary key:no_cek_stok

foreign key: kode_pegawai references pegawai(kode_pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

cek_stok_detail(no_cek_stok,kode_barang,jumlah_stok) primary key:no_cek_stok,kode_barang

foreign key: no_cek_stok references cek_stok(no_cek_stok) ON UPDATE CASCADE ON DELETE NO ACTION kode _barang references barang(kode_barang)

(50)

3.2.2.e mereview Model Data Logikal Dengan User

Setelah meninjau ulang model data lokal dengan user,maka didapatkan kesimpulan bahwa model data lokal sesuai dengan kebutuhan user.

3.2.2.f Menggabungkan Model-Model Data Lokal Menjadi Model Global (Langkah Optional)

Tujuan dari tahap ini adalah untuk menggabungkan individual data model logika lokal menjadi global yang menggambarkan perusahaan.

Tabel 3.9 model data local ke global

Barang(kode_barang,nama_barang,harga_jual,harga_beli,jumlah_stok,minimal_stok) Primary key: kode_barang

Konsumen(Kode_konsumen,nama_konsumen,alamat_konsumen,telepon_konsumen) Primary key: kode_konsumen,

Pegawai(kode_pegawai,nama_pegawai,alamat_pegawai,password,kode bagian) Primary key: kode_pegawai

Foreign key:kode_bagian references bagian(kode_bagian) Bagian(Kode_bagian,nama_Bagian)

(51)

supplier(kode_supp,nama_supp,alamat_supp) primary key:kode_supp

sales_order(no_faktur,tgl_faktur,kuantitas,kode_pegawai,kode_konsumen) primary key:no_faktur

foreign key:kode_pegawai references pegawai(kode_pegawai),kode_konsumen references konsumen(kode_konsumen)

sales_order_detail(no_faktur,kode_barang,kuantitas) primary key:no_faktur,kode_barang

foreign key:no_faktur refrences sales_order(no_faktur),kode_barang references barang(kode_barang)

purchase_order(no_PO,tgl_PO,kode_pegawai,kode_supp) primary key:no_PO

foreign key: kode_pegawai references pegawai(kode_pegawai),kode_supp references supplier(kode_supp)

Purchase_order_detail(no_PO,kode_barang,tgl_PO,kuantitas) Primary key:no_PO,kode_barang

Foreign key: no_PO refrences purchase_order(no_PO),kode _barang references barang(kode_barang)

Pembayaran(no_giro,tgl_giro,no_PO,kode pegawai,kode_supp) Primary key: no_giro

(52)

pegawai(kode_pegawai),kode_supp references supp(kode_supp) cek-stok(no_cek_stok,tgl_cek_stok,kode_pegawai)

primary key:no_cek_stok

foreign key: kode_pegawai references pegawai(kode_pegawai) cek_stok_detail(no_cek_stok,kode_barang,jumlah_stok) primary key:no_cek_stok,kode_barang

foreign key: no_cek_stok references cek_stok(no_cek_stok), kode _barang references barang(kode_barang)

(53)

(54)

3.2.2.g Memeriksa Pertumbuhan Di Masa Depan

Rancangan basis data yang dibuat masih memungkinkan untuk diperluas jika user memiliki suatu keperluan di waktu akan datang.Seperti memerlukan tampilan gaji karyawan, history berkerja dll.

3.2.3 Perancangan Basis Data Fisikal

Perancangan ini merupakan perancangan yang merupakan proses yang menghasilkan sebuah deskripsi atau gambaran implementasi basis data pada media penyimpanan yang menggambarkan hubungan dasar,organisasi data dan indeks-indeks yang memungkinkan pengaksesan data lebi cepat.Langkah-langkahnya sebagai berikut:

Tahap 3 M enterjemahkan model data logikal terhadpat DBM S yang ditentukan 1. M erancang relasi dasar

2. merancang representasi derived data 3. merancang general constraints Tahap 4 M erancang organisasi file dan index

4. menganalisis transaksi 5. memilh organisasi file 6. memilih index

(55)

Tahap 5 M erancang user views Tahap 6 M erancang keamanan 3.2.3.a Merancang Relasi Dasar

Pada langkah pertama merupakan perancangan Database Design Language (DBDL) untuk setiap entity yang bertujuan untuk membuat domain dari setiap atribut berdasarkan penjelasan berserta batasan yang ada dalam setiap atribut,yaitu :

DBDL untuk Barang

Domain Kode Barang fixed length character string, length 6, format: [B][R][0-9][0-9][0-9][0-9]

Domain Nama Barang variable length character string, length 30 Domain Harga_Jual variable length numeric, length 10,2 Domain Jumlah Stok integer

Barang (

Kode_Barang Kode Barang NOT NULL,

Nama_Barang Nama Barang NOT NULL,

Harga Harga NOT NULL,

Jumlah_Stok Jumlah Stok NOT NULL,

PRIM ARY KEY (Kode_Barang) );

(56)

DBDL untuk Bagian

Domain Kode Bagian fixed length character string, length 4, format: [B][G][0-9][0-9]

Domain Nama Bagian variable length character string, length 30 Bagian (

Kode_Bagian Kode Bagian NOT NULL,

Nama_Bagian Nama Bagian NOT NULL,

PRIM ARY KEY (Kode_Bagian) );

DBDL untuk Pegawai

Domain Kode Pegawai fixed length character string, length 6, format: [P][G][0-9][0-9][0-9][0-9]

Domain Nama Pegawai variable length character string, length 30 Domain Alamat Pegawai variable length character string, length 100 Domain Password variable length character string, length 10

Domain Kode Bagian fixed length character string, length 4, format: [B][G][0-9][0-9]

Pegawai (

Kode_Pegawai Kode Pegawai NOT NULL,

Nama_Pegawai Nama Pegawai NOT NULL,

Alamat_Pegawai Alamat Pegawai NOT NULL,

(57)

Kode_Bagian Kode Bagian NOT NULL, PRIM ARY KEY (Kode_Pegawai),

FOREIGN KEY Kode_Bagian REFERENCES Bagian (Kode_Bagian) ON UPDATE CASCADE ON DELETE NO ACTION

);

DBDL untuk Telp_Pegawai

Domain Telepon Pegawai variable length character string, length 15, format: [0-9] untuk setiap digit

Domain Kode Pegawai fixed length character string, length 6, format: [P][L][0-9][0-9][0-9][0-9]

Telepon_Pegawai (

Telepon_Pegawai Telepon Pegawai NOT NULL,

PRIM ARY KEY (Telepon_Pegawai),

FOREIGN KEY (Kode_Bagian) REFERENCES Pegawai (Kode_Pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

(58)

DBDL untuk S ales_order

Domain Nomor Faktur fixed length character string, length 6, format: [F][P][0-9][0-9][0-9][0-9]

Domain Tanggal Faktur datetime

Penjualan (

No_Faktur No Faktur NOT NULL,

Tgl_Faktur Tanggal Faktur NOT NULL,

PRIM ARY KEY (No_Faktur),

FOREIGN KEY (Kode_Pegawai) REFERENCES Pegawai (Kode_Pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

);

DBDL untuk S ales_order_detail Detail

Domain Nomor Faktur fixed length character string, length 6, format: [F][P][0-9][0-9][0-9][0-9]

Domain Harga Jual variable length numeric, length 10,2 Domain Kuantitas integer

(59)

Penjualan_Detail (

No_Faktur No Faktur NOT NULL,

Harga_Jual Harga Jual NOT NULL,

PRIM ARY KEY (No_Faktur, Kode_Barang),

FOREIGN KEY No_Faktur REFERENCES Penjualan (No_Faktur) ON UPDATE CASCADE ON DELETE NO ACTION

FOREIGN KEY Kode_Barang REFERENCES Barang (Kode_Barang) ON UPDATE CASCADE ON DELETE NO ACTION );

DBDL untuk Konsumen

Domain Kode Konsumen variable length character string, length 5 Domain Nama Konsumen variable length character string, length 30 Domain Alamat Konsumen variable length character string, length 100 Domain Telepon Konsumen variable length character string, length 15 konsumen (

Kode_Konsumen Kode Konsumen NOT NULL,

Nama_Konsumen Nama Konsumen NOT NULL,

Alamat_Konsumen Alamat Konsumen NOT NULL, Telepon_Konsumen Telepon konsumen NOT NULL, PRIM ARY KEY (Kode_konsumen),

ON UPDATE CASCADE ON DELETE NO ACTION );

(60)

DBDL untuk Cek_Stok

Domain Nomor Cek Stok fixed length character string, length 6, format: [C][S][0-9][0-9][0-9][0-9]

Domain Tanggal Cek Stok datetime

Penjualan (

No_Cek_Stok No Cek Stok NOT NULL,

Tgl_Cek_Stok Tanggal Cek Stok NOT NULL,

PRIM ARY KEY (No_Cek_Stok),

);

DBDL untuk Cek_Stok_Detail

Domain Nomor Cek Stok fixed length character string, length 6, format: [C][S][0-9][0-9][0-9][0-9]

Domain Jumlah Sistem integer Domain Jumlah Fisik integer

(61)

Cek_Stok-Detail (

No_Cek_Stok No Cek Stok NOT NULL,

Jumlah_Sistem Jumlah Sistem NOT NULL,

Jumlah_Fisik Jumlah Fisik NOT NULL,

Keterangan Keterangan NOT NULL,

PRIM ARY KEY (No_Cek_Stok, Kode_Barang),

FOREIGN KEY (No_Cek_Stok) REFERENCES Cek_Stok (No_Cek_Stok) ON UPDATE CASCADE ON DELETE NO ACTION

FOREIGN KEY (Kode_Barang) REFERENCES Barang (Kode_Barang) ON UPDATE CASCADE ON DELETE NO ACTION

);

DBDL untuk Supplier

Domain Kode Supplier fixed length character string, length 6, format: [S][P][0-9][0-9][0-9][0-9]

Domain Nama Supplier variable length character string, length 30 Domain Alamat Supplier variable length character string, length 100 Domain Email Supplier variable length character string, length 30 Supplier (

Kode_Supp Kode Supplier NOT NULL,

Nama_Supp Nama Supplier NOT NULL,

(62)

Kode_Bagian Kode Bagian NOT NULL, PRIM ARY KEY (Kode_Supp),

ON UPDATE CASCADE ON DELETE NO ACTION );

DBDL untuk Purchase Order

Domain Nomor Purchase Order fixed length character string, length 6, format: [P][O][0-9][0-9][0-9][0-9]

Domain Tgl Purchase Order datetime

Purchase_Order (

No_PO Nomor Purchase Order NOT NULL,

Tgl_PO Tanggal Purchase Order NOT NULL,

Kode_Supp Kode Supplier NOT NULL,

PRIM ARY KEY (No_PO),

FOREIGN KEY (Kode_Supp) REFERENCES Supplier (Kode_Supp) ON UPDATE CASCADE ON DELETE NO ACTION

(63)

);

DBDL untuk Purchase_Order_Detail

Domain Kode Purchase Order fixed length character string, length 6, format: [P][O][0-9][0-9][0-9][0-9]

Domain Kuantitas integer Purchase_Order_Detail (

No_PO Nomor Purchase Order NOT NULL,

Kuantitas Kuantitas PRIM ARY KEY (Kode_PO, Kode_Barang),

FOREIGN KEY (Kode_PO) REFERENCES Purchase_Order (Kode_PO) ON UPDATE CASCADE ON DELETE NO ACTION

FOREIGN KEY (Kode_Barang) REFERENCES Supplier (Kode_Barang) ON UPDATE CASCADE ON DELETE NO ACTION

);

DBDL untuk Pembayaran

Domain Nomor Giro fixed length character string, length 6, format: [P][P][0-9][0-9][0-9][0-9]

(64)

Pembayaran (

No_PP Nomor Purchase Payment NOT NULL,

Tgl_PP Tgl Purchase Payment NOT NULL,

Kode_Supp Kode Supp NOT NULL,

PRIM ARY KEY (Kode_PP),

FOREIGN KEY (Kode_Pegawai) REFERENCES Kode Pegawai (Kode_Pegawai) ON UPDATE CASCADE ON DELETE NO ACTION

FOREIGN KEY (Kode_Supp) REFERENCES Supplier (Kode_Supp) ON UPDATE CASCADE ON DELETE NO ACTION

)

3.2.3.b Merancang Representasi Derived data

Tujuan dari tahap ini adalah untuk menampilkan kembali bagaimana derived data yang tapil pada model data logikal ke global pada target DBM S.Atribut yang nilainya dapat dihasilkan dengan memriksa nilai dari atribut lain dikenal dengan nama derived atau calculated attribute.ontohnya sebagai berikut:

(65)

Tabel 3.10 Tabel Sales order

No_faktur Tgl_faktur Kode_pegawai Total_penjualan

FP0001 5 okt 2010 PG0002 300000,00

Tabel 3.11 Tabel Sales order Detail

No_faktur Kode_barang kuantitas Harga_jual

FP0001 BR0001 1 50000,00

FP0001 BR0003 2 250000,00

Dari contoh di atas total penjualan didapat suatu nilai dari attribute lain.Total penjualan di dapat pada table sales order detail yang memiliki atribut yang dihubungkan oleh No_faktur.sales order dengan dengan sales order detail merupakan suatu entury yang saling berhubungan sehingga dapat mempengaruhi atribut satu sama lain.Total penjualan didapat dari kuantitas x kode barang.

3.2.3.c Merancang General Constraint

Tujuan dari tahap ini yaitu merancang general constraint untuk DBM S. Dalam sistem ini terdapat beberapa aturan bisnis yang harus dipenuhi.

Berikut ini adalah general constraint yang akan dibuat untuk menjaga intedritas dari data yang disimpan.

(66)

• Kuantitas barang yang dijual

kuantitas barang yang dijual tidak boleh melebihi jumlah stok yang tersedia create table sales_order(

no_faktur char(6) NOT NULL tgl_faktur datetime NOT NULL kode_pegawai char(6) NOT NULL constraint [kuantitaspenjualan]

CHECK(NOT EXIST(SELECT Jumlah_stok from Barang group by kode_barang

having kuantitas>jumlah stok)), primary key (no_faktur),

on update cascade on delete no action,

foreign key(kode_pegawai) references pegawai (kode_pegawai) on update cascade on delete no action

);

3.2.3.d Menganalisis Transaksi

Analisis transaksi bertujuan untuk lebih memahami secara fungsional transaksi-transaksi yang berjalan dalam basis data dan untuk menganalisi transkasi-transaksi penting.

(67)

1. M emasukkan data pegawai 2. M emasukkan data barang 3. M emasukkan data sales order 4. M emasukkan data stok 5. memasukkan data supplier 6. memasukkan data purchase order 7. memasukkan data sales order 8. memasukkan data pembayaran

9. melakukan update/delete data pegawai 10.melakukan update/delete data barang 11.melakukan update/delete data konsumen 12.melakukan update/delete data sales order 13.melakukan update/delete data cek stok 14.melakukan update/delete data supplier 15.melakukan update/delete data purchase order 16.melakukan update/delete data pembayaran 17.menampilkan data pegawai

18.mencari data pegawai berdasarkan nama pegawai 19.menampilkan data barang

20.mencari data barang berdasarkan nama barang 21.menampilkan data sales order

(68)

23.menampilakn data cek stok

24.mencari data cek stok berdasarkan nomor cek stok 25.mencari data cek stok berdasarkan tanggal penyesuaian 26.menampilkan data supplier

27.mencari data supplier berdasarkan nama supplier 28.menampilkan data purchase order

29.M encari data purchase order berdasarkan kode purchase order 30.menampilkan data pembayaran

31.mencari data pembayaran berdasarkan nomor

Tabel 3.12 Referensi Silang Transaksi Dengan Relasi

1 2 3 4 I R U D I R U D I R U D I R U D Barang x bagian x pegawai x x supplier cek_stok x x cek_stok_detail x x sales_order x x sales_order_detail x x purchase_order x purchase_order_detail x pembayaran x konsumen

(69)

5 6 7 8 I R U D I R U D I R U D I R U D Barang bagian pegawai supplier x cek_stok cek_stok_detail sales_order x sales_order_detail x purchase_order x x purchase_order_detail x pembayaran x x konsumen 9 1 0 1 1 1 2 I R U D I R U D I R U D I R U D Barang x x bagian pegawai x x supplier cek_stok x cek_stok_detail x sales_order x x x x sales_order_detail x x purchase_order purchase_order_deta il x pembayaran x konsumen x x

(70)

1 3 1 4 1 5 1 6 I R U D I R U D I R U D I R U D Barang bagian pegawai x x supplier x x x x cek_stok x x x cek_stok_detail x sales_order sales_order_detail purchase_order x x x purchase_order_det ail x pembayaran x x konsumen 1 7 1 8 1 9 2 0 I R U D I R U D I R U D I R U D Barang x x bagian pegawai x x supplier cek_stok x cek_stok_detail x sales_order x sales_order_detail x purchase_order x purchase_order_det ail x pembayaran x konsumen

(71)

2 1 2 2 2 3 2 4 I R U D I R U D I R U D I R U D Barang bagian pegawai supplier cek_stok x x cek_stok_detail x sales_order x x sales_order_detail x x purchase_order purchase_order_det ail pembayaran konsumen 2 5 2 6 2 7 2 8 I R U D I R U D I R U D I R U D Barang bagian pegawai supplier x x cek_stok x cek_stok_detail sales_order sales_order_detail purchase_order x x purchase_order_det ail x pembayaran x konsumen

(72)

29 30 31 I R U D I R U D I R U D Barang bagian pegawai supplier cek_stok cek_stok_detail sales_order sales_order_detail purchase_order x purchase_order_detail x pembayaran x x konsumen

3.2.3.e Memilih organisasi file ¾ Pemilihan DBMS

Pemilihan DBM S merupakan pemilihan DBM S yang sesuai untuk mendukung aplikasi basis data. Berikut ini merupakan pertimbangan pemilihan DBM S antara SQL Server 2005 dan Oracle 9i.

(73)

Tabel 3.13 Perbandingan Platform

SQL Server 2005 Oracle 9i

Hanya bekerja pada platform berbasis Windows.

Bisa bekerja pada semua platform mulai dari platform berbasis Windows, Compaq Tru64, UNX, system berbasis AIX, sistem HP-UX, Linux Intel.

Tabel 3.14 Perbandingan Hardware Requirements Keterangan SQL Server 2005 Oracle 9i Processor M inimal menggunakan Pentium 600

MHz Pentium III sampai 1 GHz.

Untuk Intel/platform kompatibel lain: Pentium 166 MHz atau lebih.

Untuk AIX: IBM RISC/6000 atau Server Series

Memory M inimal membutuhkan 512 M B RAM

Untuk Windows: 128 M B RAM (minimum) dan 256 M B RAM (dianjurkan) Hard disk Database Engine and data file,

Replication, and Full Text Search (150 M B)

140 M B pada System Drive + 4.5 GB untuk the Oracle Home Drive (FAT)

(74)

Analysis Services and data file (35 M B)

Reporting Services and Reporting Manager (40 M B)

Notification Services Engine Components, Client Components and Rules Components (5 M B)

Integration Services (9 M B) Client Components (12 M B) Development Tools (70 M B)

Samples and Sample Database (390 M B)

atau 2.8 GB untuk The Oracle Home Drive (NTFS)

Typical Installation: minimal 450 s/d 550 M b Compact Installation: minimal 350 s/d 400 M b

Table 3.15 Perbandingan Dialect SQl Server 2005 dan Oracle 9i Feature SQl Server 2005 : T-SQL Oracle 9i – PL/S QL

Indexes B-Tree indexes B-Tree indexes, Bitmap indexes, Partitioned indexes, Function Based indexes, Domain indexes Tables Relational tables

Temporary tables

Relational tables, Object Tables, Temporary tables

(75)

Triggers AFTER triggers, INSTEAD OF triggers

BEFORE triggers, AFTER triggers

Procedures T-SQL statements PL/SQL statements, Java Methods, third generation language (3GL) routines

Arrays Supported Not supported

Table 3.16 Tabel Perbandingan Keterbatasan Fitur SQL Server 2005 dengan Oracle 9i

Feature SQl Server 2005 Oracle 9i

Column Name Length 128 30

Index Name Length 128 30

Table Name Length 128 30

View Name Length 128 30

Stored Procedure Name Length

128 30

Mix Column per Index 16 32

Max char() size 8000 2000

Max varchar() size 8000 4000

Max Column per Table 1024 1000

(76)

Max Query Size 16777216 16777216

Recursive Subqueries 40 64

Constant String Size in SELECT

16777207 4000

Constant String Size in WHERE

8000 4000

Table 3.17 Perbandingan Harga Number of CPUs SQl Server 2005

Standart Edition Oracle 9i Standart Edition 1 $ 5,999 $ 17,500 2 $ 11,998 $ 35,000 4 $ 23,996 $ 70,000 8 $ 47,992 $ 140,000 16 $ 95,984 $ 280,000 32 $ 191,968 $ 560,000

Dari data-data di atas menunjukan bahwa Oracle 9i mempunyai kemampuan yang lebih baik daripada SQL Server 2005, namun dari segi hardware requirements dan biaya yang harus dikeluarkan untuk DBM S tersebut relatif lebih tinggi. Atas

(77)

pertimbangan di atas, maka penulis memilih SQL Server 2005 sebagai DBM S yang akan digunakan dalam implementasi basis data.

3.2.3.f Memilih Index

Tujuan pada tahap ini adalah untuk meningkatkan peforma dari sistem dengan menggunkan index.Berikut adalah tabel index yang mebantu dalam pencarian data yang sering digunakan,yaitu :

Tabel 3.18 Tabel Index

Entitiy Primary Key Index

Barang Kode_Barang Idx_kode_barang

Purchase_Order No_PO Idx_No_PO Sales_Order No_Faktur Idx_No_Faktur

Konsumen Kode_Konsumen Idx_Kode_Konsumen

3.2.3.g Mengestimasi Kapasitas Penyimpanan yang Dibutuhkan

Tujuan dari tahap ini adalah untuk menghitung kapasitas penyimpanan yang dibutuhkan oleh basis data. Perkiraan kapasitas setiap tabel adalah sebagai berikut:

Tabel 3.19 Estimasi Tabel Bagian

Field Data Type Ukuran

Kode_Bagian Nama_Bagian Char Varchar 4 30

(78)

Kapasitas dari Tabel Bagian adalah 34 Byte.

Diperkirakan dalam satu tahun terjadi penambahan 1 bagian.

Dalam satu tahun pertumbuhan dari tabel Bagian adalah 1*34=34 Byte.

Tabel 3.20 Estimasi Tabel Pegawai

Kode_Pegawai Nama_Pegawai Alamat_Pegawai Telepon Password Kode_Bagian Char Varchar Varchar Varchar Varchar Char 6 30 100 15 10 4

Kapasitas dari Tabel Pegawai adalah 165 Byte.

Diperkirakan dalam satu tahun terjadi penambahan 1 Pegawai baru.

(79)

Tabel 3.21 Estimasi Tabel Konsumen

Kode_Konsumen Nama_Konsumen Alamat_Konsumen Telepon Char Varchar Varchar Varchar 6 30 100 15

Kapasitas dari Tabel Konsumen adalah 151 Byte.

Diperkirakan dalam satu bulan terdapat penambahan 100 konsumen.

Dalam satu tahun pertumbuhan dari tabel Konsumen adalah 1*12*100*151=181200 Byte.

Tabel 3.22 Estimasi Tabel Barang

Kode_Barang Nama_Barang Harga_Jual Harga_Beli M inimal_Stok Jumlah_Stok Char Varchar Numeric(10,2) Numeric(10,2) Integer Integer 6 30 12 12 5 5

(80)

Kapasitas dari Tabel Barang adalah 70 Byte.

Diperkirakan dalam satu tahun terjadi penambahan 20 barang baru.

Dalam satu tahun pertumbuhan dari tabel Barang adalah 20*70=1400 Byte.

Tabel 3.23 Estimasi Tabel Sales_Order

No_Faktur Tgl_Faktur Kode_Pegawai Kode_Konsumen Char Datetime Char Char 6 8 6 4

Kapasitas dari Tabel Sales_Order adalah 24 Byte. Diperkirakan dalam satu hari terjadi 20 transaksi.

Dalam satu tahun pertumbuhan dari tabel Sales_Order adalah 20*30*12*24= 172800 Byte.

(81)

Tabel 3.24 Estimasi Tabel Sales_Order_Detail

No_Faktur Kuantitas Kode_Barang Char Integer Char 6 50 6

Kapasitas dari Tabel Sales_Order_Detail adalah 62 Byte. Diperkirakan dalam satu hari terjadi 20 transaksi.

Diperkirakan setiap transaksi terdapat 5 barang.

Dalam satu tahun pertumbuhan dari tabel Sales_Order_Detail adalah 20*5*30*12*62= 2232000 Byte.

Tabel 3.25 Estimasi Tabel Cek_Stok

No_Cek_Stok Tgl_Cek_Stok Kode_Pegawai Char Datetime Char 6 8 6

Kapasitas dari Tabel Cek_Stok adalah 20 Byte. Diperkirakan dalam satu hari terjadi 20 transaksi.

(82)

Dalam satu tahun pertumbuhan dari tabel Cek_Stok adalah 20*30*12*20= 144000 Byte.

Tabel 3.26 Estimasi Tabel Cek_Stok_Detail

No_Cek_Stok Jumlah_Stok Kode_Barang Char Integer Char 6 5 6

Kapasitas dari Tabel Tabel Cek_Stok_Detail adalah 17 Byte. Diperkirakan dalam satu hari terjadi 20 transaksi.

Diperkirakan setiap transaksi terdapat 5 jenis barang.

Dalam satu tahun pertumbuhan dari tabel Tabel Cek_Stok_Detail adalah 20*5*30*12*17= 612 Kilo byte.

(83)

Tabel 3.27 Estimasi Tabel Supplier

Kode_Supp Nama_Supp Alamat_Supp Telepon Char Varchar Varchar Varchar 6 30 100 15

Kapasitas dari Tabel Supplier adalah 151 Byte.

Diperkirakan dalam satu tahun terjadi penambahan 5 supplier baru.

Dalam satu tahun pertumbuhan dari tabel Supplier adalah 5*151 = 755 Byte.

Tabel 3.28 Estimasi Tabel Purchase_Order

No_PO Tgl_PO Kode_Pegawai Kode_Supp Char Datetime Char Char 6 8 6 6

Kapasitas dari Tabel Purchase_Order adalah 26 Byte. Diperkirakan dalam satu bulan terjadi 300 transaksi.

(84)

Dalam satu tahun pertumbuhan dari tabel Purchase_Order adalah 1*300*12*26=93600 Byte.

Tabel3.29 Estimasi Tabel Purchase_Order_Detail

No_PO Kuantitas Kode_Barang Char Integer Char 6 28 6

Kapasitas dari Tabel Purchase_Order_Detail adalah 40 Byte. Diperkirakan dalam satu bulan terjadi 300 transaksi.

Dalam satu tahun pertumbuhan dari tabel Purchase_Order_Detail adalah 1*300*12*40=144000 Byte.

(85)

Tabel 3.30 Estimasi Tabel Pembayaran

No_Giro Tgl_Giro Kode_Supp Kode_Pegawai No_PO Char Datetime Char Char Char 6 8 6 6 6

Kapasitas dari Tabel Pembayaran adalah 32 Byte. Diperkirakan dalam satu bulan terjadi 300 transaksi.

Dalam satu tahun pertumbuhan dari tabel Pembayaran adalah 1*300*12*32=115200 Byte.

Tabel 3.31 Estimasi Disk S pace yang Dibutuhkan

Tabel Kapasitas ysng dibutuhkan dalam 1 tahun

Bagian 34 Byte Pegawai 165 Byte Konsumen 181200 Byte Barang 1400 Byte Sales_Order 172800 Byte Sales_Order_Detail 2232000 Byte Cek_Stok 144000 Byte

(86)

Cek_Stok_Detail 612000 Byte

Supplier 755 Byte

Purchase_Order 93600 Byte

Purchase_Order_Detail 144000 Byte

Pembayaran 115200 Byte

3.2.3.h Merancang User Interface

Tujuan dari tahap ini adalah merancang user views yang telah teredintifikas i selama tahap requirements collection and analysis data dalam siklus pengembangan basis data.

View Pegawai

CREATE VIEW view_pegawai

AS SELECT h.kode_pegawai,h.nama_pegawai, h.alamat_pegawai, d.telp_pegawai, h.password, b.kode_bagian

FROM pegawai h, telp_pegawai d , bagian b

WHERE h.kode_pegawai=d.kode_pegawai AND h.kode_bagian=b.kode_bagian View Konsumen

CREATE VIEW view_konsumen

AS SELECT h.kode_konsumen, h.nama_konsumen, h.alamat_konsumen, d.telp_konsumen.

(87)

FROM konsumen h, telp_konsumen d

WHERE h.kode_konsumen=d.kode_konsumen View Supplier

CREATE VIEW view_supplier

AS SELECT h.kode_supp, h.nama_supp, h.alamat_supp, d.telp_supp FROM supplier h, telp_supp d

WHERE h.kode_supp=d.kode_supp View S ales_Order

CREATE VIEW sales_order

AS SELECT h.no_faktur, h.tgl_faktur, h.kode_pegawai, h.kode_konsumen FROM sales_order h, sales_order_detail d, pegawai p, barang b

WHERE h.no_faktur = d.no_faktur AND h.kode_pegawai = p.kode_pegawai AND d.kode_barang = b.kode_barang

GROUP BY h.no_faktur, h.tgl_faktur, h.kode_pegawai, h.kode_konsumen View S ales_Order_Detail

CREATE VIEW view_sales_order_detail

AS SELECT h.no_faktur, b.kode_barang, d.kuantitas FROM sales_order_detail d, barang b,sales_order h

(88)

View Cek_Stok

CREATE VIEW view_cek_stok

AS SELECT h.no_cek_stok, h.tgl_cek_stok, h.kode_pegawai FROM cek_stok h, pegawai p

WHERE h.kode_pegawai = p.kode_pegawai View Cek_Stok_Detail

CREATE VIEW view_cek_stok_detail

AS SELECT d.kode_barang, b.nama_barang, d.jumlah_stok, FROM cek_stok_detail d, barang b, cek_stok h

WHERE d.kode_barang=b.kode_barang AND h.no_cek_stok=d.no_cek_stok View Purchase_Order

CREATE VIEW view_purchase_order

AS SELECT h.no_PO, h.tgl_PO, h.kode_pegawai, h.kode_supp FROM Purchase_Order h, supplier s, pegawai p

WHERE h.kode_supp = s.kode_supp AND h.kode_pegawai = p.kode_pegawai View Purchase_Order_Detail

CREATE VIEW view_purchase_order_detail AS SELECT h.no_PO, d.kode_barang, d.kuantitas

FROM purchase_order_detail d, barang b, purchase_order h WHERE d.kode_barang=b.kode_barang AND h.no_PO=d.no_PO

(89)

3.2.3.i Merancang Mekanisme Keamanan

Tujuan dari tahap ini adalah untuk merancang mekanisme keamanan dari basis data. Adapun mekanisme keamanan yang dirancang untuk basis data adalah sebagai berikut:

a) Keamanan Sistem

Keamanan Sistem diterapkan dengan menggunakan authentikasi user, yaitu dengan menggunakan halaman login sebelum masuk ke dalam sistem yang dirancang pada aplikasi. Dari halaman login, user diminta memasukkan username dan password. Selain itu, juga diatur agar user hanya bisa mengakses modul-modul tertentu dalam program sesuai dengan haknya.

b) Keamanan Data

Keamanan data berhubungan dengan relasi basis data (tabel atau relasi) dan aksi user terhadap tersebut misalnya aksi pemilihan, pengisian, pengubahan dan penghapusan data. Keamanan data ini diterapkan menggunakan autohorisasi user dengan tujuan untuk membatasi hak akses user terhadap relasi yang ada.