bab iii hebron

67

BAB III

ANALISA DAN PERANCANGAN SISTEM

Titik tolak analisa dan perancangan adalah sistem berjalan. Materi utama

dan lingkup kerja sistem berjalan di dalam menangani materi utamanya tersebut

akan dilihat secara jelas. Selanjutnya adalah tindakan identifikasi untuk menyorot

secara tepat sisi dunia nyata demi tercapainya tujuan pengembangan sistem sesuai

kebutuhan real.

3.1 Materi Utama Analisa

Materi utama analisa skripsi ini adalah materi utama milik sistem berjalan

berupa transaksi penerimaan order muatan barang. Yang lebih menekankan pada

persediaan truck guna untuk melayani customer yang tercatat sebagai member.

Perbedaan penerimaan order pada umumnya adalah setiap supir tidak boleh

menerima order diluar daftar customer yang tercatat sebagai member.

69

3.2 Analisa Sistem Berjalan

Sistem berjalan di dalam menangani raport sampai sejauh ini memiliki

cara kerja sendiri. Berikut ini adalah gambaran nyata yang dipresentasikan

memalui mapping chart.

Gambar 3.1 Mapping Chart Sistem Berjalan

70

Keterangan:

Orang-orang atau bagian-bagian yang terlibat adalah Customer, Customer

Service, Operasional, Unit Manajer. Adapun tugas-tugas mereka adalah sebagai

berikut:

1. customer: memesan truck kepada penyedia truck (ekspidisi);

2. customer service: melayani customer dalam permintaan order muatan

barang yang kemudian meminta persetujuan dari Unit Manajer;

3. operasional: Menginput data order dari customer;

4. unit manajer: pimpinan yang bertanggung jawab penuh atas semua

aktifitas permintaan order dari customer, berhak dan tanggung jawan

atas pemecatan (PHK) kepada karyawan yang melakukan kesalahan

dalam pekerjaan.

3.3 Identifikasi Sistem Berjalan

Identifikasi terhadap sistem yang berjalan diperlukan agar dapat menemukan

beberapa hal penting yang memiliki kaitan dengan sistem yang diusulkan untuk

dikembangkan. Tiga hal pokok hasil temuin proses ini adalah:

1. Sering terjadi kesalahan pada saat penginputan laporan harian, sehingga

harus dikoreksi ulang.

2. Kurang fleksible dalam transaksi penerimaan order muatan barang

sehingga sering terjadi keterlambatan pengiriman truck kepada customer.

3. Terlalu banyak keterlibatan user dalam mengoperasikan aplikasi sehingga

terkesan ribet.

71

3.4 Kebutuhan Sistem Berjalan

Dengan adanya hasil identifikasi sistem berjalan sebagaimana sudah

dipaparkan di atas, maka analisa terhadap kebutuhan sistem berjalan diperlukan.

Kebutuhan ini sangat fundamental untuk perancangan sistem ke depan.

Pertama: Kebutuhan Diadakannya Pembagian Tugas

1. tugas administrasi tidak hanya menginput data pesan/order truck.

Selebihnya:

Tetapi mengelola data-data dari subcont/ekspidisi luar yang

dipakai.

Mencetak laporan setiap harinya untuk Unit Manajer.

Mencetak surat perintah kerja untuk supir.

2. tugas kepala operasional seyogyanya tidak hanya menerima order dari

customer sebagaimana biasa. Selebihnya mereka dapat:

3. mencari ketersediaan truck dari eksipidisi luar, sehingga pesanan truck

dari customer bias terpenuhi dan tidak mengandalkan.

4. Kepala unit manajer memiliki tugas menerima laporan, menyetujui

keberangkatan truck, menyetujui penyewaan truck dari ekspidisi luar

dan menandatanganinya.

5. Customer adalah subjek yang paling pokok untuk dilayani dan

memberikan kepuasan agar semuanya berjalan dengan baik.

72

Kedua: Kebutuhan Diadakannya Sistem Database.

Database adalah gudang data. Database untuk sistem informasi ini

dirancang sedemikian rupa sehingga sesuai kebutuhan dasar. Hasil

perancangannya dipasang di komputer server. Sistem database dalam

lingkup client-server dapat untuk bekerja bagi beberapa pemakai

secara multitasking dan real time. Customer service mengelola

database sesuai hak akses yang ada padanya.

Ketiga: Kebutuhan Diadakannya Sistem Terdistribusi.

Dengan hardware dan software yang layak dan memenuhi syarat

untuk diadakannya sistem database berskala organisasi, lebih-lebih

karena sudah ada LAN terpasang, maka tinggallah pengaturan

komputer pusat untuk server dan komputer-komputer terbagi untuk

client. Customer service bertugas di bagian server sesuai hak aksesnya

sembari memantau jalannya data dan menangani hal-hal teknis lain

termasuk cetak laporan setiap saat, sedangkan operasional

menghadapi satu komputer client untuk input, update, delete, atau

save data-data yang dibutuhkan.

Keempat: Kebutuhan Diadakannya Sistem Aplikasi.

Kebutuhan ini sangat terkait dengan pengguna (user), yakni

khususnya operasional, yang dalam lingkup ini tegolong end

user/naive user. Karenanya kebutuhan diadakannya sistem aplikasi

yang dimaksud adalah kebutuhan akan user interface yang fiendly,

73

easy-going, dan easy-to-use dalam berbagai situasi penggunaan.

Sistem aplikasi dipasang di tiap-tiap komputer client lengkap dengan

sistem logon dan yang lain yang tentu saja sama dalam perancangan

interface-nya. Hal ini memungkinkan terjadinya multitasking yang

menuntut DBMS yang memadai.

3.5 Perancangan Sistem yang Dikembangkan

Alat atau tool perancangan sistem yang dikembangkan bernama UML

(Unified Modelling Language), ERD (Entity Relatinship Diagram), Relasi antar

database, spesifikasi file. Sejak di sini mulai berperan. Peran ERD tersebut sangat

fundamental karena memberikan landasan bagi tindakan perancangan database.

Tugas inti UML yang meliputi Use Case, Activity Diagram, Class

Diagram, Sequence Diagram yaitu menganalisa sistem yang akan dikembangkan

sehingga menjadi sistem yang diinginkan.

3.5.1 Use Case Diagram

Use case melaporkan interaksi antara actor di dalam sistem transaksi

penerimaan order muatan barang (study kasus pada PT Duta Lintas Nusa Bekasi)

berbasis client server. Seperti dijelaskan pada Table 3.1 berikut:

No Actor Description

1 Customer Service Orang yang memasukkan, menghapus, dan

memperbaharui data penerimaan order dari

customer

2 Operasional Orang yang mencari ketersediaan truck, mencetak

laporan penerimaan order, dan mencetak SPK

3 Customer Orang yang memesan truck dan menerima SPK

4 Unit Manajer Orang yang menerima laporan pesan truck.

74

Selanjutnya Tabel 3.2 berikut menggambarkan interaksi antar actor pada

Tabel 3.1 dengan sistem.

Tabel 3.2 Daftar Diagram Use Case

No Use Case Description Actor

1 Login Use case menggambarkan

kegiatan memasukkan username

dan password untuk dapat

mengakses sistem

Customer

Service,

Operasional,

Unit Manajer

2 Mengelola data

Customer

Use Case ini digunakan saat

Customer Service ingin

melakukan input, edit, delete,

dan melihat secara detail data

customer

Customer

Service

3 Mengelola data

truck





truck

Customer

Service

4 Mengelola data

pesan





pesan/Order

Customer

Service

5 Mengelola data

subcont





subcont

Customer

Service

6 Mengelola data

SPK





SPK

Customer

Service

75

7 Mengelola data

supir





truck

Customer

Service

8 Open File Email Use Case ini digunakan saat

Customer Service menerima

pesan/order muatan barang dari

customer melalui email

Customer

Service

9 Mencetak Laporan

pesan/order

muatan barang


operasional mencetak laporan

pesan /order muatan barang yang

masuk

Operasional

10 Mencetak SPK

(Surat Perintah

Kerja)


operasional mencetak SPK

(Surat Perintah Kerja) yang

ditujukan untuk customer

Operasional

11 Memesan Truck Use Case ini digunakan saat

Customer memesan truck kepada

Customer Service

Customer

12 Menerima SPK

(Surat Perintah

Kerja)

Use Case Ini ini digunakan saat

Customer menerima SPK (Surat

Perintah Kerja) dari operasional

Customer

13 Menerima laporan

pesan/order

muatan barang


Operasional memberikan

laporan pesan/order muatan

barang kepada Unit Manajer

Unit Manajer

Gambar 3.2 menunjukkan use case diagram yang menggambarkan

kegiatan yang terdapat dalam Tabel 3.2.

76

Gambar 3.2 Use Case Diagram

77

Ketererangan gambar:

Dalam use case diagram, actor yang terdapat dalam sistem ini ada 4. Yaitu

customer service yang bertugas melayani langsung customer yang memesan truck

untuk membawa barang produksi sesuai dengan tujuan, bias melalui via email

atau telpon. Yang meliputi mengelola data customer, mengelola data truck,

mengelola data pesan, mengelola data subcont, mengelola data SPK (Surat Printah

Kerja), mengelola data supir.

Actor yang kedua adalah operasional bertugas mencetak laporan, mencetak

SPK yang include untuk diterima oleh customer, dan mencari ketersediaan truck

jika ada customer yang memesan truck. Untuk selanjutnya laporan diterima oleh

Unit Manajer yang memiliki peran actor ketiga.

Actor yang keempat adalah customer memiliki peran diluar sistem dan

hanya memesan truck yang include untuk diterima oleh customer service dan

menerima laporan SPK (Surat Perintah Kerja).

Proses yang terjadi pada use case diagram diatas lebih lanjut dijelaskan

secara rinci pada table 3.1.

Tabel 3.1 Skenario Use Case “Login”

Nama Use Case Login

Aktor Customer Service, Operasional, dan Unit Manajer

Deskripsi Use Case menggambarkan kegiatan memasukkan

username dan password untuk mengakses sistem

Prakondisi Actor memasukkan username dan password untuk

dapat masuk kedalam sistem

78

Bidang khas suatu

event

Kegiatan Pelaku Respon Sistem

1. Memasukkan

username dan

password

2. Cek username dan

password

3. Menampilkan

halaman sesuai

aunthentifikasi

Bidang Alternative Alt-langkah 2. Jika username dan password benar

maka langsung masuk kedalam sistem. Jika salah

maka sistem akan menampilkan pesan kesalahan.

Kesimpulan Aktor masuk ke dalam sistem

Post Kondisi Sistem berhasil diakses

Tabel 3.2 Skenario Use Case ―Mengelola Data Customer‖

Nama Use Case Mengelola Data Customer

Aktor Customer Service

Deskripsi Digunakan oleh aktor untuk melakukan input,

edit,delete dan melihat detail data mengelola data

customer setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data

customer

Bidang khas suatu

event


1. Memilih menu input

data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan

seperti input, edit,

delete data customer

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .

Bidang Alternative Alt-langkah 5: jika aktor memilih tombol batal

maka form input data customer akan kembali

kosong dan dan tidak tersimpan dalam database

79

Kesimpulan Customer service berhasil melakukan pengolahan

data customer

Post Kondisi Data customer tersimpan ke dalam database

Tabel 3.3 Skenario Use Case ―Mengelola Data Truck‖

Nama Use Case Mengelola Data Truck




truck setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data truck

Bidang Khas Suatu

Even



data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan


delete data truck

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .


maka form input data truck akan kembali kosong

dan dan tidak tersimpan dalam database


data truck

Post Kondisi Data truck tersimpan ke dalam database

80

Tabel 3.4 Skenario Use Case ―Mengelola Data Pesan‖

Nama Use Case Mengelola Data Pesan




pesan setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data pesan

Bidang Khas Suatu

Even



data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan


delete data pesan

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .


maka form input data pesan akan kembali kosong



data pesan

Post Kondisi Data pesan tersimpan ke dalam database

81

Tabel 3.5 Skenario Use Case ―Mengelola Data Subcont‖

Nama Use Case Mengelola Data Subcont




subcont setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data

subcont

Bidang Khas Suatu

Even



data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan


delete data subcont

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .


maka form input data subcont akan kembali kosong



data subcont

Post Kondisi Data subcont tersimpan ke dalam database

82

Tabel 3.6 Skenario Use Case ―Mengelola Data SPK‖

Nama Use Case Mengelola Data SPK




SPK setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data SPK

Bidang Khas Suatu

Even



data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan


delete data SPK

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .


maka form input data SPK akan kembali kosong



data SPK

Post Kondisi Data SPK tersimpan ke dalam database

Tabel 3.7 Skenario Use Case ―Mengelola Data Supir‖

Nama Use Case Mengelola Data Supir




supir setelah login ke dalam sistem

Prakondisi Aktor memasukkan data-data mengelola data supir

83

Bidang Khas Suatu

Even



data

2. Menampilkan menu

input data

3. Customer service

ingin melakukan

beberapa tindakan


delete data supir

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

5. Customer Service

melakukan

penyimpanan data

6. Sistem akan

melakukan

penyimpanan data

yang telah

dilakukan oleh

aktor .


maka form input data supir akan kembali kosong



data supir

Post Kondisi Data supir tersimpan ke dalam database

Tabel 3.8 Skenario Use Case ―Open File Email‖

Nama Use Case Open File Email


Deskripsi Digunakan oleh aktor untuk melakukan pengecekan

pemesanan truck via email

Prakondisi Aktor mencari data pesan

Bidang Khas Suatu

Even


1. Memilih menu email

dari gmail atau yahoo

2. Menampilkan email

masuk

3. Customer service

ingin melakukan

beberapa tindakan

seperti mencari data

pesan

4. Menampilkan file

email masuk

pemesanan truck

dari customer

84

5. Customer Service

melakukan pencarian

data pesan

6. Sistem akan

melakukan

pencarian data yang

telah dilakukan oleh

aktor .

Bidang Alternative Alt-langkah 5: jika aktor menemukan data pesanan

truck dan kondisi truck masih ada, maka aktor akan

melakukan input data pesan/order truck dari

customer

Kesimpulan Customer service berhasil melakukan pencarian

data pesan

Post Kondisi Data pesan/order muatan barang ditemukan

Tabel 3.9 Skenario Use Case ―Laporan pesan/order muatan barang‖

Nama Use Case Mencetak Laporan pesan/order muatan barang

Aktor Operasional

Deskripsi Use Case ini menggambarkan kegiatan melihat

laporan dan mencetak pesan/order muatan barang

yang akan diberikan kepada Unit Manajer

Prakondisi Aktor melihat hasil pesan/order muatan barang

Bidang Khas Suatu

Even


1. Memilih menu

laporan

2. Menampilkan

laporan yang berupa

tabel

3. Klik cetak untuk

mencetak laporan

4. Menghubungkan

dengan

perlengkapan

hardware yang

telah terpasang

5. Mencetak laporan

Bidang Alternative Alt-langkah 3: terdapat tombol batal jika aktor

tidak ingin melakukan cetak laporan

Kesimpulan Aktor melihat laporan pesan/order muatan barang

Post Kondisi Aktor berhasil melihat laporan pesan/order muatan

barang

85

Tabel 3.10 Skenario Use Case ―Mencetak SPK (Surat Perintah Kerja‖

Nama Use Case Mencetak SPK (Surat Perintah Kerja)

Aktor Operasional

Deskripsi Use Case ini menggambarkan kegiatan mencetak

SPK (Surat Perintah Kerja) yang akan diberikan

kepada Customer

Prakondisi Aktor mencetak SPK (Surat Perintah Kerja)

Bidang Khas Suatu

Even


1. Memilih menu

laporan

2. Menampilkan

laporan yang berupa

tabel

3. Klik cetak untuk

mencetak laporan

4. Menghubungkan

dengan

perlengkapan

hardware yang

telah terpasang

5. Mencetak laporan

SPK (Surat Perintah

Kerja)


tidak ingin melakukan cetak SPK

Kesimpulan Aktor mencetak SPK (Surat perintah Kerja)

Post Kondisi Aktor berhasil mencetak SPK (Surat Perintah

Kerja)

Tabel 3.11 Skenario Use Case ―Mencari Ketersediaan Truck‖

Nama Use Case Mencari Ketersediaan Truck

Aktor Operasional

Deskripsi Use Case ini menggambarkan kegiatan

ketersediaan truck yang dilihat berdasarkan pesan

truck dari customer, berapa banyak truck yang

masih ada dan truck yang masih beroperasi.

Prakondisi Aktor mencari ketersediaan truck berdasarkan

pemesanan truck yang sudah terjadi

86

Bidang Khas Suatu

Even


1. Memilih menu pesan

dan SPK

2. Menampilkan menu

pesan dan SPK

3. Operasional ingin

melakukan kegiatan

pencarian ketsediaan

truck berdasarkan

pesan truck dan SPK

5. Operasional

melakukan pencarian

data pesan dan SPK

4. Menampilkan form

yang telah

dilakukan beberapa

tindakan atau alert

6. Sistem melakukan

pencarian data yang

telah dilakukan oleh

aktor

Bidang Alternative Alt-langkah 3: terdapat tombol batal jika

operasional sudah menemukan data truck yang

masih ada dan belum beroperasi.

Kesimpulan Aktor menemukan ketersediaan truck

Post Kondisi Aktor berhasil menemukan ketersediaan truck

Tabel 3.12 Skenario Use Case ―Memesan Truck‖

Nama Use Case Memesan Truck

Aktor Customer

Deskripsi Digunakan oleh aktor untuk melakukan pemesanan

truck kepada Customer Service

Prakondisi Aktor memesan truck kepada Customer Service

Bidang Khas Suatu

Even


1. Memesan truck -

Bidang Alternative -

Kesimpulan Aktor memesan truck kepada Customer Serivice

Post Kondisi Aktor berhasil memesan truck

87

Tabel 3.13 Skenario Use Case ―Menerima Laporan‖

Nama Use Case Mencetak Laporan Menerima Laporan Pesan/Order

Aktor Unit Manajer

Deskripsi Use Case ini menggambarkan kegiatan melihat

laporan atau mencetak laporan pesan/order muatan

barang.

Prakondisi Aktor melihat hasil laporan atau mencetak

pesan/order muatan barang

Bidang Khas Suatu

Even


6. Memilih menu

laporan

7. Menampilkan

laporan yang berupa

tabel

8. Klik cetak untuk

mencetak laporan

9. Menghubungkan

dengan

perlengkapan

hardware yang

telah terpasang

10. Mencetak laporan


tidak ingin melakukan cetak laporan

Kesimpulan Aktor melihat laporan atau mencetak laporan


Post Kondisi Aktor berhasil melihat laporan atau mencetak


88

3.5.2 Activity Diagram

Gambar 3.3 Activity Diagram

89

3.5.3 Class Diagram

Gambar 3.4 Class Diagram

90

3.5.4 Sequence Diagram

1. Use Case: Login

Gambar 3.5 Diagram Sekuen - Login

2. Use Case: Memasukkan Data Customer

Gambar 3.6 Diagram Sekuen – Memasukkan data customer

91

3. Use Case: Mengubah Data Customer

Gambar 3.7 Diagram Sekuen – Mengubah data customer

92

4. Use Case: Menghapus Data Customer

Gambar 3.8 Diagram Sekuen – Menghapus data customer

93

5. Use Case: Memasukkan Data Truck

Gambar 3.9 Diagram Sekuen – Memasukkan data truck

94

6. Use Case: Mengubah Data Truck

Gambar 3.10 Diagram Sekuen – Mengubah data truck

95

7. Use Case: Menghapus Data Truck

Gambar 3.11 Diagram Sekuen – Menghapus data truck

96

8. Use Case: Memasukkan Data Order/Pesan

Gambar 3.12 Diagram Sekuen – Memasukkan data Pesan/Order

97

9. Use Case: Mengubah Data Order/Pesan

Gambar 3.13 Diagram Sekuen – Mengubah data pesan/order

98

10. Use Case: Menghapus Data Order/Pesan

Gambar 3.14 Diagram Sekuen - Menghapus data pesan/order

99

11. Use Case: Memasukkan Data SPK

Gambar 3.15 Diagram Sekuen – Memasukkan data SPK

100

12. Use Case: Mengubah Data SPK

Gambar 3.16 Diagram Sekuen – Mengubah data SPK

101

13. Use Case: Menghapus Data SPK

Gambar 3.17 Diagram Sekuen – Menghapus data SPK

102

14. Use Case: Memasukkan Data Subcont

Gambar 3.18 Diagram Sekuen – Memasukkan data subcont

103

15. Use Case: Mengubah Data Subcont

Gambar 3.19 Diagram Sekuen – Mengubah data subcont

104

16. Use Case: Menghapus Data Subcont

Gambar 3.20 Diagram Sekuen – Menghapus data subcont

105

17. Use Case: Memasukkan Data Supir

Gambar 3.21 Diagram Sekuen – Memasukkan data supir

106

18. Use Case: Mengubah Data Supir

Gambar 3.22 Diagram Sekuen – Mengubah data supir

107

19. Use Case: Menghapus Data Supir

Gambar 3.23 Diagram Sekuen – Menghapus datasupir

108

20. Use Case: Transaksi

Gambar 3.24 Diagram Sekuen - Transaksi

3.6 ERD Sistem yang Dikembangkan

ERD (Entity Relationship Diagram) akan menggunakan keenam datastore

tersebut dalam lingkup relasinya. Relasi tersebut melalui sebuah cara yang disebut

kardinalitas relasi/derajat relasi. Hal terakhir ini penting karena adanya saling

terikat antar datastore di dalam relasi melalui derajatnya itu.

Namun keenam datastore di atas—sebagaimana ketentuan di dalam

ERD—kini berstatus baru. Entitas dalam adalah status barunya itu. Namun

pengertian entitas di sini berbeda dengan pengertian entitas pada DFD. Entitas

pada DFD adalah entitas luar (external entity), artinya ada lingkungan luar sistem

yang terlibat di dalam sistem tetapi belum tentu termasuk bagian dalam dari

sistem yang dikembangkan. Sedangkan entitas pada ERD adalah entitas dalam

(internal entity), artinya ada lingkungan dalam sistem yang terlibat di dalam

sistem dan termasuk bagian dalam dari sistem yang dikembangkan.

109

Karena sifatnya, entitas dalam memiliki atribut-atribut. Atribut-atribut ada

dalam lingkaran berbentuk elips. Atribut-atribut itu dengan sendirinya sedang

mengatakan tentang diri entitas dalam. Unsur terakhir itulah yang memungkinkan

terjadinya relasi antar-entitas dalam tersebut.

Berikut ini adalah ERD untuk sistem yang dikembangkan:

Gambar 3.25 Rancangan ERD

110

Penjelasan:

1. Datastore ―customer‖ untuk custo memiliki primermary key ―ic‖ untuk id

customer. Dengan derajat relasi one to many, melalui primary key ini

berelasi dengan datastore ―pesan‖. Nama relasinya adalah ―memiliki‖.

2. Datastore ―pesan‖ untuk pesan memiliki primary key ―np‖ untuk no

pesan. Dengan derajat relasi many to one, melalui primary key tersebut

datastore ini berelasi dengan datastore ―truck‖. Nama relasinya adalah

―membantu‖.

3. Datastore ―truck‖ untuk truck memiliki primary key ‖nt‖ untuk no truck.

Dengan derajat relasi many to many, melalui primary key tersebut

datastore ini berelasi dengan datastore ―supir‖. Nama relasinya adalah

―membantu‖.

4. Datastore ―pesan‖ untuk pesan memiliki primary key ―np‖ untuk no

pesan. Datastore ini menampung data-data pada datastore ―spk‖ dan

―subcont‖ untuk tujuan mempermudah proses penginputan data. Derajat

relasi dengan keduanya adalah one to many. Nama relasinya adalah

―memiliki‖.

3.7 Kamus Data Sistem yang Dikembangkan

1. Kamus Data Datastore ―customer‖

Nama Datastore : customer

Primary Key : id_customer

Foreign Key : -

Primary Key Type : Varchar

Foreign Key Type : -

Primary Key Length : 15

Foreign Key Key Length : -

Medium Penyimpanan : Internal Hard Disc

111

Field Type Length Description

ic Varchar 20 Id Customer

nm Varchar 60 Nama

almt Varchar 120 Alamat

tlpn Char 15 Telepon

kp Char 6 Kode Pos

fax Char 15

Fax

bank Varchar 35 Bank

profil Varchar 200 Profil

bisnis Varchar 120 Bisnis

fb Float 8 Fee Borongan

ft Float 8 Fee Tonase

Tabel 3.1 Kamus Data Datastore ―customer‖

2. Kamus Data Datastore ―pesan‖

Nama Datastore : pesan

Primary Key : np

Foreign Key : -







np Varchar 20 No Pesan

spkn Varchar 45 Spk No

Status Varchar 5 Status

date Date - Date

cs Varchar 60 Customer

prdk Varchar 50 Produk

tt Varchar 20 Tipe Truck

distance Char 10 Distance

dari Varchar 35 From

Tujuan Varchar 35 To

tarif Float 8 Tarif

ppk Float 8 Price Per Kg

tq Float 8 Total Quantity

ic Varchar 20 Id Customer

Tabel 3.2 Kamus Data Datastore ―pesan‖

112

3. Kamus Data Datastore ―spk(surat perintah kerja)‖

Nama Tabel : spk

Primary Key : np

Foreign Key : -

Primary Key Type : Char







spkn Varchar 45 Spk No

dt Date 8 Date

cs Varchar 60 Customer

nt Varchar 8 No Truck

ns Varchar 50 Nama Supir

Tabel 3.3 Kamus Data Datastore ―spk‖

4. Kamus Data Tabel Datastore ―subcont‖

Nama Datastore : subcont

Primary Key : np

Foreign Key : -

Primary Key Type : Char







nm Varchar 60 Nama

almt Varchar 60 Alamat

nt Char 15 No Telepon

Tabel 3.4 Kamus Data Datastore ―subcont‖

113

5. Kamus Data Datastore ―truck‖

Nama Datastore : truck

Primary Key : nt

Foreign Key : -







nt Varchar 8 No Truck

tt Varchar 20 Tipe Truck

bm Float 10 Berat Max

is Float 10 Isi Max

lk Float 10 Last KM

Tabel 3.5 Kamus Data Datastore ―truck‖

6. Kamus Data Datastore ―supir‖

Nama Datastore : supir

Primary Key :

Foreign Key : -







is Varchar 20 Id Supir

ns Varchar 50 Nama Supir

ss Varchar 15 Status Supir

nh Char 15 No Hp

Tabel 3.6 Kamus Data Datastore ―supir‖

114

3.8 Relasi Antar Database

Gambar 3.26 Rancangan Relasi Antar Tabel

bab iii hebron

Documents