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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Bab iii hebron

Similar to Bab iii hebron (20)

Bab iii hebron