BAB III ANALISA DAN PERANCANGAN 3.1 Gambaran Umum

BAB III
ANALISA DAN PERANCANGAN
3.1
Gambaran Umum Perusahaan
Dibawah ini akan dibahas secara ringkas gambaran umum tentang
perusahaan Raja Kepiting, seperti sejarah perusahaan, struktur organisasi,
wewenang dan tanggung jawab dari masing – masing bagian pekerjaan.
3.1.1
Sejarah Perusahaan
Raja Kepiting merupakan sebuah perusahaan yang bergerak
dibidang restoran. Menu utama yang disajikan di restoran Raja Kepiting
adalah makanan seafood. Restoran Raja Kepiting yang pertama didirikan
pada tanggal 17 Agustus 2006, berlokasi di Jalan Raya Serpong KM 7
No. 35 Serpong (Depan WTC Matahari).
Tujuan didirikannya Restoran Raja Kepiting ini adalah untuk
memenuhi para penikmat makanan seafood pada khususnya. Telah
menjadi komitmen, Restoran Raja Kepiting hanya akan menyediakan
hidangan kepiting dengan kualitas terbaik saja. Kepiting yang disajikan
pun berasal dari berbagai wilayah Indonesia, seperti Tarakan dan Timika.
Kepiting merupakan menu unggulan yang disajikan oleh restoran
ini. Saus kepiting yang terbaik dan digemari adalah lada hitam (black
pepper) dan saus padang (chili sauce), namun masih tersedia saus lain
yang tidak kalah lezatnya, seperti saus tiram (oyster sauce), asam manis
67
68
(sweet and sour sauce), goreng mentega (fried butter sauce), dan telor
asin (salted egg).
Untuk makanan jenis seafood, di restoran ini pun menyajikan ikan
laut/ tawar, kerang, sup asparagus jagung kepiting, dan lain-lain. Namun
bagi pengunjung yang tidak bisa menikmati makanan laut, restoran ini
menyediakan olahan ayam, bakmi, bihun dan kwetiau.
Melihat peluang bisnis yang ada, maka Restoran Raja Kepiting
membuka cabang di beberapa tempat. Ruko Flourite FR 33 Summarecon
Gading Serpong dan Food Court Rame Rame di Tangcity Mall pun
menjadi tempat yang digunakan untuk memperlebar bisnis restoran ini.
3.1.2
Struktur Organisasi
Dalam suatu organisasi, terdapat hubungan diantara sumber daya
manusia dengan segala aktivitas bisnis yang ada. Semakin banyak
kegiatan yang dilakukan dalam suatu organisasi, semakin kompleks
hubungan-hubungan yang ada. Untuk itu perlu dibuat suatu bagan yang
menggambarkan hubungan-hubungan tersebut yaitu dengan struktur
organisasi.
Struktur organisasi perusahaan harus memungkinkan adanya
koordinasi kerja antara semua satuan dan jenjang untuk tindakantindakan dalam mencapai tujuan umum perusahaan.
69
Struktur organisasi memerinci pembagian aktivitas kerja dan
selain itu struktur organisasi juga menunjukkan hirarki dari organisasi,
pembagian tugas, tanggung jawab dan wewenang.
Berikut ini merupakan struktur organisasi dari Restoran Raja
Kepiting.
Gambar 3.1 Struktur Organisasi
70
3.1.3
Wewenang dan Tanggung Jawab
Wewenang dan tanggung jawab masing-masing bagian pada
Restoran Raja Kepiting adalah sebagai berikut:
•
Owner, memiliki wewenang dan tanggung jawab antara lain:
-
Pengambilan kebijakan perusahaan
-
Berhak atas pengurangan tenaga kerja
-
Memiliki prioritas utama dalam pengambiilan keputusan penting
yang menyangkut restoran Raja Kepiting
-
Menerima laporan para penanggung jawab dari setiap cabang
restoran
•
Branch Manager, memiliki wewenang dan tanggung jawab antara
lain:
-
Bertanggung jawab terhadap kebijakan operasional
-
Mempunyai wewenang operasional
-
Mengawasi operasional harian perusahaan
-
Memonitor serta mengontrol pelayanan dari Food & Beverage
Production dan Food & Beverages Service
•
Kitchen Head, memiliki wewenang dan tanggung jawab antara lain:
-
Mengorganisasikan penyediaan stok makanan dan minuman
-
Memonitor serta mengontrol pelayanan dari Food & Beverage
Production
•
Food & Beverage Production, memiliki wewenang dan tanggung
jawab antara lain:
71
-
Membuat makanan dan minuman dari pesanan tamu restoran
-
Mengkoordinasikan penyajian makanan dan minuman dengan
Food & Beverage Service
•
Finance & Accounting, memiliki wewenang dan tanggung jawab
antara lain:
•
-
Bertugas mengatur keuangan restoran
-
Bertanggung jawab atas laporan keuangan restoran
-
Memoitor serta mengontrol pelayanan dari Cashier
Cashier, memiliki wewenang dan tanggung jawab antara lain :
-
•
Bertanggung jawab atas transaksi pembayaran
Food & Beverage Service, memiliki wewenang dan tanggung jawab
antara lain :
3.2
-
Bertugas untuk melayani tamu restoran
-
Bertugas menyajikan makanan dan minuman untuk tamu
-
Bertugas sebagai penerima pesanan makanan dan minuman
Analisa Sistem yang Sedang Berjalan
Sistem yang sedang berjalan pada Restoran Raja Kepiting untuk proses
pemesanan makanannya masih menggunakan kertas, sedangkan untuk bagian
kasir menggunakan alat kasir yang umum digunakan. Analisis sistem yang
sedang berjalan diwakilkan / digambarkan oleh Data Flow Diagram (DFD).
72
3.2.1
DFD Sistem yang Sedang Berjalan
Berikut adalah gambaran sistem yang sedang berjalan pada
restoran yang dilukiskan dengan menggunakan Data Flow Diagram
(DFD)
yang
merupakan
alat
bantu
penting
digunakan
untuk
menggambarkan sistem informasi suatu organisasi, pada kasus ini adalah
sistem informasi pada restoran Raja Kepiting.
3.2.1.1 Diagram Konteks
Gambar 3.2 Diagram Konteks Sistem yang Sedang Berjalan
73
3.2.1.2 Diagram Nol
Gambar 3.3 Diagram Nol Sistem yang Sedang Berjalan
3.3
Proses Bisnis Perusahaan
Merupakan proses bisnis yang terjadi sehari – hari pada restoran yang
akan diuraikan sebagai berikut.
3.3.1
Prosedur Pemesanan Makanan
Berikut ini adalah prosedur untuk memesan makanan pada
Restoran Raja Kepiting :
1. Pelanggan yang datang akan langsung diantar ke meja yang tersedia.
74
2. Kemudian pelayan akan memberikan daftar menu makanan kepada
pelanggan.
3. Pelanggan memilih menu makanan dan kemudian pelayan akan
mencatatnya pada kertas yang telah disediakan.
4. Setelah itu pelayan akan menyerahkan kertas pesanan tersebut ke
bagian dapur.
Gambar 3.4 Proses Bisnis Pemesanan Makanan
3.3.2
Prosedur Penambahan Pesanan Makanan
Jika pelanggan akan menambah pesanan, maka berikut ini adalah
prosedur yang dilakukan :
1. Pelanggan akan memanggil pelayan.
75
2. Pelayan akan mencatat pesanan tambahan yang diinginkan oleh
pelanggan.
3. Kemudian pesanan tersebut akan diserahkan ke bagian dapur.
Gambar 3.5 Proses Bisnis Penambahan Pesanan Makanan
3.3.3
Prosedur Pembayaran Tagihan
Jika pelanggan telah selesai makan, maka prosedur untuk
melakukan pembayaran adalah sebagai berikut :
1. Pelanggan datang ke kasir.
2. Kemudian kasir akan memberikan total tagihan kepada pelanggan,
3. Lalu pelanggan memberikan uang ke kasir.
4. Kasir akan mencatat tagihan dan jumlah pembayaran ke mesin kasir.
76
5. Selanjutnya kasir memberikan struk tagihan, dan jika ada uang
kembali, maka akan diserahkan kepada pelanggan.
Gambar 3.6 Proses Bisnis Pembayaran Tagihan
3.3.4
Prosedur Pembelian Stok Bahan Makanan
Berikut ini merupakan prosedur untuk melakukan pembelian stok
bahan makanan pada Restoran Raja Kepiting :
1. Bagian dapur akan melaporkan stok bahan makanan yang hampir
habis kepada Manager.
2. Manager menerima daftar bahan makanan tersebut, kemudian
menyetujui pembelian tersebut.
3. Bagian dapur akan menerima uang dari Manager, lalu bagian dapur
akan membeli bahan makanan tersebut.
4. Khusus untuk pembelian bahan makanan dalam jumlah yang besar,
seperti kepiting, udang, pihak Manager akan meminta pemasok untuk
mengirimkan bahan makanan tersebut sesuai permintaan.
77
5. Bahan makanan yang sudah dikirimkan oleh pemasok akan disimpan
terlebih
dahulu
di
gudang
penyimpanan
sebelum
akhirnya
didistribusikan ke cabang-cabang Restoran Raja Kepiting.
Gambar 3.7 Proses Bisnis Pembelian Stok Bahan Makanan
3.4
Analisis Permasalahan yang Dihadapi
Setelah dilakukan analisis pada sistem yang sedang berjalan, dan
berdasarkan data – data yang didapat dari hasil observasi dan wawancara, maka
didapatkan beberapa kendala atau masalah yang dihadapi Restoran Raja
Kepiting.
78
3.4.1
Permasalahan yang Sedang Dihadapi
Permasalahan yang saat ini sedang dihadapi oleh Restoran Raja
Kepiting adalah sebagai berikut :
1. Penyajian makanan yang tidak sesuai dengan yang seharusnya,
misalnya 1 porsi udang mentega harusnya ada 8 buah udang, tapi
yang disajikan hanya 6 buah udang.
2. Terjadi kesalahan penulisan menu makanan oleh pelayan, sehingga
pihak restoran harus mengganti menu yang sesuai dengan keinginan
pelanggan.
3. Untuk laporan pemasukan masih tidak tersusun dengan rapi, karena
menggunakan kertas pesanan (struk).
4. Stok bahan makanan tidak begitu dapat dikontrol dengan baik, salah
satu contohnya ada karyawan yang sengaja menjual beberapa bahan
makanan tersebut ke pihak lain tanpa sepengetahuan Kepala Dapur
ataupun Manager.
3.4.2
Usulan Pemecahan Masalah
Dari permasalahan yang terjadi tersebut, usulan pemecahan
masalah-masalah yang dihadapi antara lain :
1. Sistem yang dibuat akan menampilkan menu secara detail, sehingga
pelanggan akan mengetahui bahan makanan yang digunakan serta
jumlah bahan pokok setiap porsinya.
79
2. Pelanggan yang akan memesan sendiri menu makanannya, sehingga
meminimalkan kesalahan yang terjadi saat proses pemesanan.
3. Sistem akan menyimpan riwayat pesanan dan total tagihan ke dalam
database, sehingga akan memudahkan pihak restoran untuk melihat
data laporan pemasukan.
4. Sistem stok yang akan dibuat akan menyimpan dan menampilkan
jumlah stok yang masuk.
.
3.5
DFD Sistem yang Diusulkan
Berikut ini adalah diagram aliran data dari sistem yang diusulkan kepada
restoran Raja Kepiting, yang terdiri dari diagram konteks dan diagram nol, yang
dapat dilihat sebagai berikut :
3.5.1
Diagram Konteks
Gambar 3.8 Diagram Konteks Sistem yang Diusulkan
80
3.5.2
Diagram Nol
Gambar 3.9 Diagram Nol Sistem yang Diusulkan
81
3.6
Perancangan Basis Data
Dari hasil analisis sistem yang akan digunakan pada restoran Raja
Kepiting, dilakukan perancangan basis data yang dibagi dalam tiga tahapan
proses, yaitu :
a. Perancangan basis data konseptual (conceptual database design)
b. Perancangan basis data logical (logical database design)
c. Perancangan basis data fisikal (physical database design)
3.6.1
Perancangan Basis Data Konseptual
Perancangan basis data tahap konseptual melingkupi proses
pembuatan model data untuk digunakan pada sistem basis data restoran
Raja Kepiting. Langkah pertama dalam perancangan basis data
konseptual adalah membangun satu atau lebih konseptual datamodel dari
kebutuhan organisasi.
3.6.1.1 Identifikasi Tipe Entitas
Dilakukan identifikasi untuk menentukan tipe entitas yang
diperlukan. Tujuan dari tahap ini adalah untuk menentukan entitas
utama yang dibutuhkan, kemudian dilakukan dokumentasi ke
dalam sebuah tabel yang berisi nama entitas, deskripsi, alias, dan
kejadian yang terjadi pada tiap entitas.
82
Tabel 3.1 Identifikasi Tipe Entitas
No
Entitas
Pegawai
Deskripsi
Orang-orang
Alias
Employee
Occurrence
Setiap pegawai
yang berkerja di
bekerja pada
perusahaan
satu bidang
1
tertentu
Meja
Perlengkapan
yang
2
Table
digunakan
sebagai
tempat
makan
untuk
Setiap
pelanggan
memiliki
satu
meja makan
pelanggan
Pesanan
Menggambarkan
Order
Setiap pesanan
pesanan produk
yang dilakukan
yang dilakukan
oleh pelanggan
3
pelanggan
MenuMakanan
4
Menggambarkan
Produk
Setiap menu
hasil dari bahan
makanan yang
baku yang telah
dihasilkan dari
di proses menjadi
proses produksi
makanan
StokBahanMakanan Menggambarkan
5
bahan makanan
yang digunakan
Raw
Setiap bahan
material
makanan yang
ada di stok
83
untuk membuat
produk
Pembayaran
6
Menggambarkan
Payment
Setiap
proses
pembayaran
pembayaran
dilakukan jika
pesanan
pelanggan telah
selesai makan
Review
Mengambarkan
Review
Review
proses feedback
dilakukan jika
pelanggan
pelanggan telah
terhadap
selesai makan
7
makanan yang
dimakan
3.6.1.2 Identifikasi Tipe Relasi
Dilakukan identifikasi untuk menentukan tipe relasi atau
hubungan-hubungan antar entitas yang sudah didefinisikan.
Tujuan dari tahap ini adalah untuk menentukan hubungan penting
antara entitas-entitas yang telah diidentifikasi.
Langkah – langkah dalam identifikasi tipe relasi adalah
sebagai berikut :
84
a. Perancangan ERD (Entity Relationship Diagram)
0..*
Menghitung_Stok
StokBahanMakanan
1..*
Memengaruhi_Menu
1..*
1..1
Memengaruhi_Stok
Pegawai
1..*
MenuMakanan
1..1
1..*
1..*
0..1
Melakukan_Pemesanan
Review
Menerima_Pembayaran
Pesanan
1..*
1..1
Menghasilkan_Pembayaran
1..1
Memberikan_Saran_Komentar
0..*
Pembayaran
0..*
1..1
Meja
1..1
Melengkapi_Pesanan
1..*
1..1
Melakukan_Pembayaran
Gambar 3.10 Entity Relationship Diagram tahap Konseptual
85
b. Penentuan multiplicity dari hasil relasi
Tabel 3.2 Identifikasi Tipe Relasi
Entitas
Pegawai
Multiplicity
Relationship
Multiplicity
Entitas
1..1
Menghitung_
0..*
StokBahanMakanan
0..*
Pembayaran
0..1
Review
1..*
Pesanan
0..*
Pembayaran
1..1
Pembayaran
1..*
Pesanan
1..*
Menu Makanan
1..*
Pesanan
Stok
1..1
Menerima_Pe
mbayaran
Meja
1..1
Memberikan_
Saran_Komen
tar
1..1
Melakukan_P
emesanan
1..1
Melakaukan_
Pembayaran
Pesanan
1..1
Menghasilkan
_Pembayaran
MenuMakanan
1..*
Melengkapi_P
esanan
StokBahanMakanan
1..*
Memengaruhi
_Menu
1..*
Memengaruhi
_Stok
86
3.6.1.3 Identifikasi dan Asosiasi Atribut
Dilakukan
identifikasi
untuk
mendefinisikan
dan
menjelaskan tiap entitas dan asosiasinya. Tujuan dari langkah inni
adalah untuk mengidentifikasi dan mengasosiasikan atribut dari
suatu entitas atau tipe relasi. Identifikasi dan asosiasi atribut
dengan tipe entitas atau relationship, dapat dilihat di tabel berikut:
Tabel 3.3 Identifikasi Atribut dengan Tipe Entitas
Tipe Data
Entitas
Atribut
MultiNULL
Deskripsi
valued
& Panjang
Pegawai
IdPegawai
Atribut unik untuk
Char (5)
Tidak
Tidak
identifikasi
pegawai
NamaPegawai
Nama pegawai
Varchar(30)
Tidak
Tidak
Jabatan
Jabatan pegawai
Varchar (20)
Tidak
Tidak
JenisKelamin
Jenis kelamin
Char (1)
Tidak
Tidak
Date
Tidak
Tidak
pegawai
TanggalLahir
Tanggal lahir
pegawai
Alamat
Alamat pegawai
Varchar (200)
Tidak
Tidak
NomorHP
Nomor HP
Varchar (16)
Ya
Tidak
Char (3)
Tidak
Tidak
Pegawai
Meja
IdMeja
Atribut unik untuk
identifikasi
87
pelanggan
NamaMeja
Nomor meja
Varchar(10)
Tidak
Tidak
Varchar (10)
Tidak
Tidak
Varchar (5)
Tidak
Tidak
Int
Tidak
Tidak
Char (5)
Tidak
Tidak
pelanggan
Username
Username untuk
login aplikasi
Password
Password untuk
login aplikasi
Status
Status dari meja
tersebut
Pesanan
IdPesanan
Atribut unik untuk
identifikasi
pesanan makanan
NamaMenu
Nama menu
Varchar(100)
Tidak
Tidak
JumlahPesanan
Jumlah pesanan
Int
Tidak
Tidak
Float
Tidak
Tidak
Float
Tidak
Tidak
Date
Tidak
Tidak
Int
Tidak
Tidak
Char (5)
Tidak
Tidak
pelanggan
Harga
Harga satuan
menu makanan
TotalHarga
Total harga
keseluruhan
pesanan pelanggan
TanggalPesan
Waktu pesanan
makanan
StatusPesanan
Status pesanan
makanan
MenuMakana
IdMenu
Atribut unik untuk
88
n
identifikasi menu
makanan
NamaMenu
Nama menu
Varchar (30)
Tidak
Tidak
Float
Tidak
Tidak
Varchar (100)
Ya
Tidak
Char (5)
Tidak
Tidak
makanan
Harga
Harga satuan
menu makanan
Deskripsi
Deskripsi dari
menu makanan
StokBahanMa
IdStok
kanan
Atribut unik untuk
identifikasi stok
bahan makanan
NamaBahan
Nama bahan
Varchar (15)
Tidak
Tidak
SatuanUkuran
Satuan ukuran
Varchar (6)
Tidak
Tidak
HargaSatuanUkuran
Harga satuan
Float
Tidak
Tidak
ukuran bahan
MinimumStok
Minimum stok
Int
Tidak
Tidak
JumlahStok
Jumlah stok yang
Int
Tidak
Tidak
Date
Tidak
Tidak
Char (5)
Tidak
Tidak
Float
Tidak
Tidak
ada
TanggalMasuk
Tanggal masuk
bahan makanan
Pembayaran
IdPembayaran
Atribut unik untuk
identifikasi
pembayaran
TotalHarga
Total harga
pesanan menu
89
makanan
JumlahPembayaran
Jumlah
Float
Tidak
Tidak
Float
Tidak
Tidak
Date
Tidak
Tidak
Char (5)
Tidak
Tidak
Varchar (50)
Tidak
Tidak
Date
Tidak
Tidak
pembayaran yang
diberikan
pelanggan
JumlahUangKembali
Jumlah uang
kembalian
pelanggan
TanggalPembayaran
Tanggal
pembayaran
Review
IdReview
Atribut unik untuk
identifikasi review
Review
Isi review
pelanggan
Tanggal
Tanggal pengisian
review
3.6.1.4 Determinasi Domain Atribut
Dilakukan identifikasi untuk menentukan atribut domain
pada model data tahap konseptual lokal. Atribut domain adalah
kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut.
Atribut domain merupakan fitur yang sangat kuat dalam model
relational. Setiap atribut di dalam relasi ditetapkan dalam domain.
90
Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih
atribut mungkin ditetapkan dalam domain yang sama.
Tabel 3.4 Determinasi Domain Atribut
Entitas
Pegawai
Atribut
IdPegawai
Domain Atribut
5 karakter dengan format Exxxx, dimana karakter ‘E’
merupakan kode pegawai dan empat karakter berikutnya
merupakan nomor pegawai
NamaPegawai
Variasi karakter dengan maksimal jumlah 50 karakter
Jabatan
Variasi karakter dengan maksimal jumlah 20 karakter
JenisKelamin
Sebuah karakter ‘M’ untuk jenis kelamin laki-laki atau ‘F’
untuk jenis kelamin perempuan
Meja
TanggalLahir
Tanggal dengan format dd-mm-yyyy
Alamat
Variasi karakter dengan maksimal jumlah 100 karakter
NomorHP
Variasi karakter dengan maksimal jumlah 14 karakter
IdMeja
5 karakter dengan format Cxxxx, dimana karakter ‘C’
merupakan kode pelanggan dan empat karakter berikutnya
merupakan nomor pelanggan
Pesanan
NamaMeja
Variasi karakter dengan maksimal jumlah 10 karakter
Username
Variasi karakter dengan maksimal jumlah 15 karakter
Password
Variasi karakter dengan maksimal jumlah 5 karakter
Status
Angka bulat (non-desimal)
IdPesanan
5 karakter dengan format Oxxxx, dimana karakter ‘O’
91
merupakan kode pesanan dan empat karakter berikutnya
merupakan nomor pesanan
NamaMenu
Variasi karakter dengan maksimal jumlah 10 karakter
JumlahPesanan Angka bulat (non-desimal)
MenuMakanan
Harga
Angka bulat (non-desimal)
TotalHarga
Angka bulat (non-desimal)
TanggalPesan
Tanggal dengan format dd-mm-yyyy
StatusPesanan
Variasi karakter dengan maksimal jumlah 5 karakter
IdMenu
5 karakter dengan format Mxxxx, dimana karakter ‘M’
merupakan kode menu makanan dan empat karakter
berikutnya merupakan nomor dari menu makanan tersebut
NamaMenu
Variasi karakter dengan maksimal jumlah 30 karakter
Harga
Angka bulat (non-desimal)
Deskripsi
Variasi karakter dengan maksimal jumlah 100 karakter
StokBahanMaka IdStok
5 karakter dengan format Sxxxx, dimana karakter ‘S’
nan
merupakan kode stok dan empat karakter berikutnya
merupakan nomor stok
NamaBahan
Variasi karakter dengan maksimal jumlah 15 karakter
SatuanUkuran
Variasi karakter dengan maksimal jumlah 6 karakter
HargaSatuanU
Angka bulat (non-desimal)
kuran
MinimumStok
Angka bulat (non-desimal)
JumlahStok
Angka bulat (non-desimal)
92
Pembayaran
TanggalMasuk
Tanggal dengan format dd-mm-yyyy
IdPembayaran
5 karakter dengan format Pxxxx, dimana karakter ‘P’
merupakan kode untuk pembayaran dan empat karakter
berikutnya merupakan nomor transaksi pembayaran
TotalHarga
Angka bulat (non-desimal)
JumlahPembay
Angka bulat (non-desimal)
aran
JumlahUangKe Angka bulat (non-desimal)
mbali
TanggalPemba
Tanggal dengan format dd-mm-yyyy
yaran
Review
IdReview
5 karakter dengan format Fxxxx, dimana karakter ‘F’
merupakan kode untuk review / feedback dan empat karakter
berikutnya merupakan nomor review
Review
Variasi karakter dengan maksimal jumlah 50 karakter
Tanggal
Tanggal dengan format dd-mm-yyyy
3.6.1.5 Menentukan Atribut Candidate, Primary dan Alternate Key
Dilakukan identifikasi untuk menentukan candidate key,
dan primary key dari setiap entitas yang ada. Candidate key
adalah sekelompok atribut yang minimal dan secara unik
mengidentifikasikan tiap kejadian dari tipe entitas. Primary key
93
adalah key yang dipilih untuk mengidentifikasikan secara unik
tiap kejadiandari tipe entitas.
Tabel 3.5 Identifikasi Candidate Key dan Primary Key
Entity
Pegawai
Candidate Key
Idpegawai
Primary Key
Idpegawai
Namapegawai
Alamat
Nomorhp
Meja
IdMeja
IdMeja
NamaMeja
Username
Pesanan
Idpesanan
Idpesanan
Namamenu
MenuMakanan
Idmenu
Idmenu
Namamenu
StokBahanMakanan Idstok
Idstok
Namabahan
Pembayaran
Idpembayaran
Idpembayaran
Review
Idreview
Idreview
94
Gambar 3.11 Entity Relationship Diagram tahap Konseptual dengan
Primary Key
95
3.6.1.6 Memeriksa Model dari Redundansi
Pada tahap ini, diperiksa apakah terdapat redundansi pada
relasi yang telah dibuat sebelumnya. Jika ditemukan adanya relasi
yang redundan atau berulang maka akan dilakukan penghilangan
hubungan redundansi yang ada. Dua langkah yang dilakukan pada
tahap ini adalah
1. Memeriksa hubungan One to One
a. Hubungan One to One antara Meja dan Review
Gambar 3.12 Hubugan Antara Meja dan Review
Entitas Meja dan Review tidak redundan dan keduanya
tidak dapat digabungkan menjadi satu entitas, karena
objek masing – masing entitas berbeda.
96
b. Hubungan One to One antara Pesanan dan Pembayaran
Gambar 3.13 Hubungan Antara Pesanan dan
Pembayaran
Entitas Pesanan dan Pembayaran tidak redundan dan
keduanya tidak dapat digabungkan menjadi satu entitas,
karena objek masing – masing entitas berbeda.
2. Memeriksa Redundansi
a. Hubungan antara Stok Bahan Makanan, Menu Makanan
dan Pesanan
•
Relasi Awal :
Gambar 3.14 Hubungan Awal Antara Stok Bahan
Makanan, Menu Makanan dan Pesanan
97
Relasi memengaruhi stok antara Pesanan dan Stok Bahan
Makanan redundan, karena data Pesanan memengaruhi
Stok Bahan Makanan dapat dilihat juga dari relasi
memengaruhi antara Stok Bahan Makanan dan Menu
Makanan. Sehingga tidak diperlukan relasi tambahan
antara Pesanan dan Stok Bahan Makanan, karena Stok
Bahan Makanan akan dipengaruhi dari jumlah yang
digunakan dalam Menu Makanan.
•
Relasi akhir :
Gambar 3.15 Hubungan Akhir Antara Stok Bahan
Makanan, Menu Makanan dan Pesanan
98
b. Hubungan antara Pembayaran, Meja dan Pesanan
•
Relasi awal :
Gambar 3.16 Hubungan Awal Antara Pembayaran,
Meja, dan Pesanan
Relasi
melakukan
pembayaran
antara
Meja
dan
Pembayaran redundan, karena data Meja melakukan
pembayaran dapat dilihat juga dari relasi menghasilkan
pembayaran antara Pesanan dan Pembayaran. Sehingga
tidak diperlukan relasi tambahan antara Meja dan
Pembayaran, karena data Meja dapat dilihat dari relasi
99
menghasilkan
pembayaran
antara
Pesanan
dan
Pembayaran.
•
Relasi akhir :
Gambar 3.17 Hubungan Akhir antara Pembayaran,
Meja, dan Pesanan
100
Gambar 3.18 Entity Relationship Diagram Konseptual Setelah Penghilangan
Hubungan Redundansi
3.6.1.7 Memvalidasi Model Transaksi Pengguna
Pada tahap ini dilakukan validasi model konseptual
dengan transaksi pengguna aplikasi. Tujuan dari tahap ini adalah
memvalidasi model konseptual yang sesuai dengan transaksi
101
pengguna aplikasi. Dibawah ini akan dijelaskan mengenai
tinjauan dari beberapa user yang ada, antara lain :
1. Pegawai memasukan stok dan atau melakukan pengecekan
terhadap ketersediaan barang (bahan makanan) yang ada.
2. Pelanggan masuk ke dalam sistem aplikasi melalui akun
yang telah diberikan, setelah itu pelanggan melakukan
pemesanan menu makanan.
3. Pelanggan memberikan saran / komentar (review) atas menu
makanan yang telah di konsumsi.
4. Pelanggan melakukan pembayaran atas tagihan yang di dapat
dari pesanan.
5. Pegawai menerima pembayaran yang dilakukan pelanggan.
102
Gambar 3.19 Validasi Model Konseptual dengan Transaksi Pengguna
3.6.2
Perancangan Basis Data Logikal
Perancangan basis data logikal adalah proses membangun sebuah
model dari data yang digunakan oleh perusahaan yang berdasar pada
model data yang spesifik, tetapi tidak terikat pada DBMS tertentu dan
pertimbangan fisikal lainnya.
Perancangan pada tahap ini meliputi proses pembuatan model
informasi basis data yang digunakan pada Restoran Raja Kepiting
103
berdasarkan model konseptual yang telah dibuat pada tahap perancangan
basis data sebelumnya.
3.6.2.1 Menentukan Relasi untuk Model Data Logikal
Pada tahap ini akan dibuat model data logikal dan
relasinya untuk memunculkan lagi entitas, relasi dan atribut –
atribut yang telah diidentifikasi pada tahap sebelumnya untuk
diturunkan. Proses penurunan relasi untuk model data logikal
dibagi dalam beberapa tahap :
a. Identifikasi Tipe Entitas Kuat
Tipe entitas kuat adalah entitas – entitas yang tidak memiliki
ketergantungan kepada entitas lain dan berdiri sendiri dengan
primary key miliknya. Tipe entitas kuat biasanya adalah
entitas awal.
Tabel 3.6 Tipe Entitas Kuat
Pegawai
(
JenisKelamin,
IdPegawai,
NamaPegawai,
TanggalLahir,
Jabatan,
Alamat,
NomorHP,
Username,
Password,
Username, Password )
Primary Key ( IdPegawai )
Meja
(
IdMeja,
NamaMeja,
TanggalDatang, Pesanan, Status )
Primary Key ( IdPelanggan )
104
Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga,
TotalHarga, TanggalPesan, StatusPesanan )
Primary Key ( IdPesanan )
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi )
Primary Key ( IdMenu )
StokBahanMakanan
SatuanUkuran,
(
IdStok,
HargaSatuanUkuran,
NamaBahan,
MinimumStok,
JumlahStok, TanggalMasuk )
Primary Key ( IdStok )
Pembayaran
(
IdPembayaran,
JumlahPembayaran,
TotalHarga,
JumlahUangKembali,
TanggalPembayaran )
Primary Key ( IdPembayaran )
Review ( IdReview, Review, Tanggal )
Primary Key ( IdReview )
b. Identifikasi Tipe Entitas Lemah
Entitas lemah terbentuk dari hasil relasi yang mempunyai
semua atribut sederhana dari entitas – entitas lainnya. Entitas
lemah tidak bisa dibuatkan primary key hingga hubungan
dengan entitas asal direlasikan terlebih dahulu.
Tidak terdapat entitas lemah dalam model data ini.
105
c. Identifikasi Tipe Binary Relationship 1:*
Pada entitas – entitas yang mempunyai hubungan one-to-many
memiliki ciri yang unik yaitu entitas yang berada di sisi one
menjadi parent, dan entitas yang berada di sisi many menjadi
child.
1. Tambahkan IdPegawai menjadi foreign key pada Pesanan
untuk hubungan 1..* melayani_pesanan antara Pegawai
dan Pesanan.
Gambar 3.20 Relasi one – to – many Antara Pegawai dan Pesanan
2. Tambahkan
IdPegawai
StokBahanMakanan
menjadi
untuk
foreign
key
hubungan
pada
1..*
menghitung_stok antara Pegawai dan StokBahanMakanan.
106
Gambar 3.21 Relasi one – to – many Antara Pegawai dan StokBahanMakanan
3. Tambahkan
IdPegawai
menjadi
foreign
key
pada
Pembayaran untuk hubungan 1..* menerima_pembayaran
antara Pegawai dan Pembayaran.
Gambar 3.22 Relasi one – to – many Antara Pegawai dan Pembayaran
4. Tambahkan IdPegawai menjadi foreign key pada Review
untuk hubungan 1..* menerima_saran_komentar antara
Pegawai dan Review.
107
Gambar 3.23 Relasi one – to – many Antara Pegawai dan Review
5. Tambahkan IdMeja menjadi foreign key pada Pesanan
untuk hubungan 1..* melakukan_pemesanan antara Meja
dan Pesanan.
Gambar 3.24 Relasi one – to – many Antara Meja dan Pesanan
108
d. Tipe Binary Relationship 1:1
Entitas – entitas yang berhubungan secara one-to-one dibuat
menjadi satu relasi yang sama menggunakan mandatory
participation pada kedua sisinya. Entitas yang terlibat
kemudian digabungkan dan dipilih satu primary key dari
entitas asal, jika ada primary key lain maka akan menjadi
alternate key.
1. Tambahkan IdMeja menjadi foreign key pada Review
untuk
relasi
1..1
yang
menggunakan
mandatory
participation memberikan_saran_komentar antara Meja
dan Review.
Gambar 3.25 Relasi one – to – one Antara Meja dan Review
109
2. Tambahkan
IdPesanan
menjadi
Pembayaran
untuk
relasi
mandatory
participation
1..1
foreign
yang
key
pada
menggunakan
menghasilkan_pembayaran
antara Pesanan dan Pembayaran.
Gambar 3.26 Relasi one – to – one Antara Pesanan dan Pembayaran
e. Tipe Binary Relationship *:*
Untuk setiap hubungan binary many-to-many, dibuat relasi
yang melambangkan hubungan antar entitas dan dimasukkan
seluruh atribut yang merupakan bagian dari relasi. Primary
key yang sama diberikan pada relasi yang baru, namun akan
berperan juga sebagai foreign key.
1. Hubungan
*..*
MenuMakanan
•
Relasi awal :
antara
StokBahanMakanan
dan
110
Gambar 3.27 Relasi Awal many – to – many antara StokBahanMakanan dan
MenuMakanan
Karena
relasi
antara
StokBahanMakanan
dan
MenuMakanan bersifat many-to-many, maka tidak bisa
secara langsung menggabungkan kedua tabel tersebut.
Diperlukan suatu tabel baru untuk dapat menggabungkan
kedua tabel tersebut.
•
Relasi akhir :
Gambar 3.28 Relasi Akhir many – to – many Antara StokBahanMakanan dan
MenuMakanan
111
2. Hubungan *:* antara MenuMakanan dan Pesanan
•
Relasi awal :
Gambar 3.29 Relasi Awal many – to – many Antara MenuMakanan dan Pesanan
Karena relasi antara MenuMakanan dan Pesanan bersifat
many-to-many,
maka
tidak
bisa
secara
langsung
menggabungkan kedua tabel tersebut. Diperlukan suatu
tabel baru untuk dapat menggabungkan kedua tabel
tersebut.
112
•
Relasi akhir :
Gambar 3.30 Relasi Akhir many – to – many Antara MenuMakanan dan Pesanan
f. Atribut Multi-Value
Atribut multi-value adalah atribut yang memiliki lebih dari 1
nilai. Jika terdapat atribut multi-value maka harus dibuatkan
satu entitas baru untuk mewakili atribut multi-value, kemudian
primary key entitas tersebut dimasukkan pada relasi yang baru
berperan sebagai foreign key.
Pada model data ini tidak terdapat atribut multi-value.
3.6.2.2 Memvalidasi Relasi Menggunakan Normalisasi
Tahap selanjutnya yaitu, melakukan normalisasi terhadap
relasi
yang
dibuat
sebelumnya.
Tahap
validasi
relasi
menggunakan normalisasi yang bertujuan untuk menghilangkan
113
anomali – anomali data yang ada. Dalam tahap ini terdapat
beberapa entitas yang sudah dalam bentuk normal, sehingga tidak
diperlukan validasi normalisasi lagi terhadap entitas tersebut.
Berikut ini adalah hasil normalisasi yang ada, yaitu :
Validasi 1NF :
Sebuah relasi dimana persimpangan setiap baris dan
kolom berisi satu dan hanya satu nilai (Connolly & Begg, 2005,
p403).
Sebuah relasi akan berada dalam bentuk 1NF jika
repeating group sudah hilang.
•
Pesanan
UNF :
Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga,
TotalHarga,
TanggalPesan,
StatusPesanan,
IdMeja,
Username, IdPegawai, NamaPegawai, IdMenu )
Hasil 1NF :
Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga,
TanggalPesan,
StatusPesanan,
IdMeja,
Username,
IdPegawai, NamaPegawai, IdMenu )
•
Menu Makanan
UNF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi,
IdStok, NamaBahan )
114
Hasil 1NF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi,
IdStok, NamaBahan )
Validasi 2NF :
Menurut Connolly dan Begg (2005, p407) relasi dikatakan
2NF jika relasi berada pada 1NF dan setiap atribut yang bukan
primary key bergantung sepenuhnya (full functionally dependent)
terhadap primary key. Full functionally dependent terjadi jika A
dan B merupakan atribut dari suatu relasi, dan B dikatakan
bergantung penuh terhadap A (A->B), namun bukan subset dari
A.
•
Pesanan
1NF :
Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga,
TanggalPesan,
StatusPesanan,
IdMeja,
Username,
IdPegawai, NamaPegawai, IdMenu )
Hasil 2NF :
Pesanan
(
IdPesanan,
TanggalPesan,
StatusPesanan,
IdMeja, Username, IdPegawai, NamaPegawai )
115
PesananDetail ( IdPesanan, IdMenu, NamaMenu, Harga,
JumlahPesanan )
•
MenuMakanan
1NF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi,
IdStok, NamaBahan )
Hasil 2NF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi )
MenuMakananDetail ( IdMenu, IdStok, NamaBahan )
Validasi 3NF :
Menurut
Connolly dan Begg
(2005,
p409),
Third
Normal Form (3NF) adalah sebuah relasi yang memenuhi first
normal form (1NF) dan second normal form (2NF) di mana tidak
terdapat atribut non-primary key yang bersifat transitively
dependent dari primary key-nya.
•
Pesanan
2NF :
Pesanan
(
IdPesanan,
TanggalPesan,
StatusPesanan,
IdMeja, Username, IdPegawai, NamaPegawai )
116
PesananDetail ( IdPesanan, IdMenu, NamaMenu, Harga,
JumlahPesanan )
Hasil 3NF :
Pesanan
(
IdPesanan,
TanggalPesan,
StatusPesanan,
IdMeja, IdPegawai )
PesananDetail
(
IdPesanan,
IdMenu,
Harga,
JumlahPesanan )
•
MenuMakanan
2NF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi )
MenuMakananDetail ( IdMenu, IdStok, NamaBahan )
Hasil 3NF :
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi )
MenuMakananDetail ( IdMenu, IdStok, NamaBahan )
117
Gambar 3.31 Entity Relationship Diagram Logikal
118
3.6.2.3 Memvalidasi Relasi dengan Transaksi Pengguna
Proses ini bertujuan untuk memastikan bahwa relasi pada
model logikal mendukung kebutuhan transaksi. Tahap ini
memeriksa bahwa relasi yang dibuat pada tahap sebelumnya juga
mendukung transaksi yang ada dan memastikan tidak ada error
yang terjadi pada saat membuat relasi. Apabila semua transaksi
dapat dipenuhi oleh model data logikal yang dibuat maka model
data logikal tersebut adalah benar.
Pada perancangan diatas, semua transaksi yang ada dapat
dipenuhi oleh model data logikal yang dibuat.
3.6.2.4 Memeriksa Integrity Constraint
Tahap ini dilakukan untuk memastikan bahwa setiap data
adalah valid dan konsisten. Berikut adalah entitas – entitas yang
digunakan beserta batasan integritasnya (integrity constraint).
Pegawai ( IdPegawai, NamaPegawai, Jabatan, JenisKelamin,
TanggalLahir, Alamat, NomorHP )
Primary Key IdPegawai
Meja ( IdMeja, NamaMeja, Username, Password, Status)
Primary Key IdMeja
119
Pembayaran ( IdPembayaran, TanggalPembayaran, Idpesanan,
IdPegawai )
Primary Key IdPembayaran
Foreign Key IdPesanan References Pesanan ( IdPesanan )
ON DELETE CASCADE ON UPDATE CASCADE
Foreign Key IdPegawai References Pegawai ( IdPegawai )
ON DELETE CASCADE ON UPDATE CASCADE
Pesanan ( IdPesanan, TanggalPesan, StatusPesanan, IdPegawai,
IdMeja )
Primary Key IdPesanan
Foreign Key IdPegawai References Pegawai ( IdPegawai )
ON DELETE CASCADE ON UPDATE CASCADE
Foreign Key IdMeja References Meja ( IdMeja )
ON DELETE CASCADE ON UPDATE CASCADE
PesananDetail ( IdMenu, IdPesanan, Qty, HargaSatuan, Total)
Primary Key IdMenu, IdPesanan
Foreign Key IdMenu References MenuMakanan ( IdMenu )
ON DELETE CASCADE ON UPDATE CASCADE
Foreign Key IdPesanan References Pesanan ( IdPesanan )
ON DELETE CASCADE ON UPDATE CASCADE
120
MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi,
IdKategoriMakanan )
Primary Key IdMenu
MenuMakananDetail ( IdMenu, IdStok, Qty )
Primary Key IdMenu, IdStok
Foreign Key IdMenu References MenuMakanan ( IdMenu )
ON DELETE CASCADE ON UPDATE CASCADE
Foreign Key IdStok References StokBahanMakanan ( IdStok)
ON DELETE CASCADE ON UPDATE CASCADE
StokBahanMakanan ( IdStok, NamaBahan, SatuanUkuran,
Harga, MinimumStok, JumlahStok, TanggalMasuk, IdPegawai )
Primary Key IdStok
Foreign Key IdPegawai References Pegawai ( IdPegawai )
ON DELETE CASCADE ON UPDATE CASCADE
Review ( IdReview, Review, TanggalReview, IdMeja, IdPegawai
)
Primary Key IdReview
Foreign Key IdMeja References Meja ( IdMeja )
ON DELETE CASCADE ON UPDATE CASCADE
Foreign Key IdPegawai References Pegawai ( IdPegawai )
ON DELETE CASCADE ON UPDATE CASCADE
121
KategoriMakanan ( IdKategoriMakanan, KategoriMakanan )
Primary Key IdKategoriMakanan
User ( Username, Password, HakAkses, IdPegawai )
Primary Key Username
3.6.2.5 Meninjau Model Data Logikal dengan Pengguna
Tahap ini bertujuan untuk meninjau ulang model data
logikal yang telah dibuat dengan pengguna untuk memastikan
bahwa model data logikal yang dibuat telah merepresentasikan
kebutuhan data organisasi secara benar.
Setelah dilakukan tinjauan dengan pengguna maka
diperoleh hasil bahwa model data logikal yang dibuat telah
merepresentasikan struktur data yang di simpan oleh organisasi.
3.6.3
Perancangan Basis Data Fisikal
Perancangan basis data fisikal bertujuan untuk menerjemahkan
data – data model logikal menjadi data – data model fisikal agar dapat
diimplementasikan pada DBMS tertentu. Tahapan ini terdiri dari desain
relasi dasar, analisis transaksi, dan estimasi kebutuhan disk space.
122
3.6.3.1 Menerjemahkan Model Data Logikal untuk DBMS
Tahapan pertama dalam perancangan basis data fisikal
adalah menerjemahkan model data logikal kedalam model data
fisikal sehingga dapat diimplementasikan pada DBMS target.
3.6.3.1.1 Desain Relasi Dasar
Menerjemahkan atribut – atribut pada model data logikal
ke dalam model data fisikal beserta bahasa SQL yang
digunakan dalam pembuatan suatu entitas.
1. Pegawai
Keterangan:
IdPegawai
: Tipe Data karakter, length 5
NamaPegawai
: Tipe Data variasi karakter, length 30
Jabatan
: Tipe Data variasi karakter, length 20
JenisKelamin
: Tipe Data karakter, length 1 harus ‘M’ atau ‘F’
TanggalLahir
: Tipe Data date
Alamat
: Tipe Data variasi karakter, length 200
NomorHP
: Tipe Data variasi karakter, length 16
CREATE TABLE Pegawai (
IdPegawai
char(5)
NOT NULL,
NamaPegawai
varchar(30)
NOT NULL,
Jabatan
varchar(20)
NOT NULL,
123
JenisKelamin
char(1)
NOT NULL,
TanggalLahir
date
NOT NULL,
Alamat
varchar(200)
NOT NULL,
NomorHP
varchar(16)
NOT NULL,
PRIMARY KEY (`IdPegawai`)
);
2. Meja
Keterangan:
IdMeja
: Tipe Data variasi karakter, length 3
NamaMeja
: Tipe Data variasi karakter, length 10
UserName
: Tipe Data variasi karakter, length 10
Password
: Tipe Data variasi karakter, length 5
Status
: Tipe Data integer, length 1
CREATE TABLE Meja (
IdMeja
char(3)
NOT NULL,
NamaMeja
varchar(10)
NOT NULL,
Username
varchar(10)
NOT NULL,
Password
varchar(5)
NOT NULL,
Status
int(1)
NOT NULL,
PRIMARY KEY (`IdMeja`)
124
);
3. Pembayaran
Keterangan:
IdPembayaran
: Tipe Data karakter, length 5
TanggalPembayaran
: Tipe Data datetime
JumlahPembayaran
: Tipe Data integer, length 7
Idpesanan
: Tipe Data karakter, length 5
IdPegawai
: Tipe Data karakter, length 5
CREATE TABLE Pembayaran (
Idpembayaran
char(5)
NOT NULL,
TanggalPembayaran
date
NOT NULL,
JumlahPembayaran
int(7)
NOT NULL,
IdPesanan
char(5)
NOT NULL,
IdPegawai
char(5)
NOT NULL,
PRIMARY KEY (`Idpembayaran`),
FOREIGN KEY (`IdPesanan`) REFERENCES Pesanan
(`IdPesanan`) ON DELETE CASCADE ON UPDATE
CASCADE,
FOREIGN KEY (`IdPegawai`) REFERENCES Pegawai
(`IdPegawai`) ON DELETE CASCADE ON UPDATE
CASCADE
);
125
4. Pesanan
Keterangan:
IdPesanan
: Tipe Data karakter, length 5
TanggalPesan
: Tipe Data datetime,
StatusPesanan
: Tipe Data Integer, length 1
IdMeja
: Tipe Data karakter, length 3
CREATE TABLE Pesanan (
IdPesanan
char(5)
NOT NULL,
TanggalPesan
date
NOT NULL,
StatusPesanan
int(1)
NOT NULL,
IdMeja
char(3)
NOT NULL,
PRIMARY KEY (`IdPesanan`),
FOREIGN
KEY
(`IdMeja`)
REFERENCES
`Meja`
(`IdMeja`) ON DELETE CASCADE ON UPDATE
CASCADE
);
5. PesananDetail
Keterangan:
IdMenu
: Tipe Data karakter, length 5
IdPesanan
: Tipe Data karakter, length 5
Qty
: Tipe Data integer, length 2
126
HargaSatuan
: Tipe Data integer, length 6
Bumbu
: Tipe Data variasi karakter, length 50
Catatan
: Tipe Data variasi karakter, length 255
Status
: Tipe Data integer, length 1
CREATE TABLE PesananDetail (
IdMenu
char(5)
NOT NULL,
IdPesanan
char(5)
NOT NULL,
Qty
int(2) unsigned
NOT NULL,
HargaSatuan
int(6) unsigned
NOT NULL,
Bumbu
varchar(50)
NOT NULL,
Catatan
varchar(255)
NOT NULL,
Status
int(1)
NOT NULL,
PRIMARY KEY (`IdMenu`,`IdPesanan`),
FOREIGN
KEY
(`IdMenu`)
REFERENCES
`MenuMakanan` (`IdMenu`) ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (`IdPesanan`) REFERENCES `Pesanan`
(`IdPesanan`) ON DELETE CASCADE ON UPDATE
CASCADE
);
127
6. KategoriMakanan
Keterangan:
IdKategoriMakanan
: Tipe Data karakter, length 3
KategoriMakanan
: Tipe Data variasi karakter, length 50
CREATE TABLE KategoriMakanan (
IdKategoriMakanan
char(3)
NOT NULL,
KategoriMakanan
char(50)
NOT NULL,
PRIMARY KEY (`IdKategoriMakanan`)
);
7. MenuMakanan
Keterangan:
IdMenu
: Tipe Data karakter, length 5
NamaMenu
: Tipe Data variasi karakter, length 100
Harga
: Tipe Data integer, length 6
Deskripsi
: Tipe Data variasi karakter, length 100
NamaGambar
: Tipe Data variasi karakter, length 50
IdKategoriMakanan
: Tipe Data karakter, length 3
128
CREATE TABLE MenuMakanan (
IdMenu
char(5)
NOT NULL,
NamaMenu
varchar(100)
NOT NULL,
Harga
int(6) unsigned
NOT NULL,
Deskripsi
varchar(100)
NOT NULL,
NamaGambar
varchar(50)
NOT NULL,
IdKategoriMakanan
char(3)
NOT NULL,
PRIMARY KEY (`IdMenu`),
FOREIGN KEY (`IdKategoriMakanan`) REFERENCES
`KategoriMakanan` (`IdKategoriMakanan`) ON DELETE
CASCADE ON UPDATE CASCADE
);
8. MenuDetail
Keterangan:
IdMenu
: Tipe Data karakter, length 5
IdStok
: Tipe Data karakter, length 5
Qty
: Tipe Data variasi karakter, length 25
CREATE TABLE MenuDetail (
IdMenu
char(5)
NOT NULL,
IdStok
char(5)
NOT NULL,
Qty
varchar(25)
NOT NULL,
129
PRIMARY KEY (`IdMenu`,`IdStok`),
FOREIGN
KEY
(`IdMenu`)
REFERENCES
`MenuMakanan` (`IdMenu`) ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN
KEY
`StokBahanMakanan`
(`IdStok`)
(`IdStok`)
REFERENCES
ON
DELETE
CASCADE ON UPDATE CASCADE
);
9. StokBahanMakanan
Keterangan:
IdStok
: Tipe Data karakter, length 5
NamaBahan
: Tipe Data variasi karakter, length 25
SatuanUkuranTotal
: Tipe Data variasi karakter, length 6
Harga
: Tipe Data integer, length 6
MinimumStok
: Tipe Data integer, length 3
SatuanUkurMin
: Tipe Data variasi karakter, length 10
JumlahStok
: Tipe Data integer, length 3
TanggalMasuk
: Tipe Data date
IdPegawai
: Tipe Data karakter, length 5
Catatan
: Tipe Data variasi karakter, length 255
CREATE TABLE StokBahanMakanan (
IdStok
char(5)
NOT NULL,
130
NamaBahan
varchar(25)
NOT NULL,
SatuanUkuranTotal
varchar(6)
NOT NULL,
Harga
int(6) unsigned
NOT NULL,
MinimumStok
int(3) unsigned
NOT NULL,
SatuanUkurMin varchar(10)
NOT NULL,
JumlahStok
int(3) unsigned
NOT NULL,
TanggalMasuk
date
NOT NULL,
IdPegawai
char(5)
NOT NULL,
Catatan
varchar(255)
NOT NULL,
PRIMARY KEY (`IdStok`),
FOREIGN KEY (`IdPegawai`) REFERENCES `Pegawai`
(`IdPegawai`) ON DELETE CASCADE ON UPDATE
CASCADE
);
10. Review
Keterangan:
IdReview
: Tipe Data karakter, length 5
Review
: Tipe Data variasi karakter, length 255
TanggalReview
: Tipe Data datetime,
IdMeja
: Tipe Data karakter, length 3
CREATE TABLE Review (
IdReview
char(5)
NOT NULL,
Review
varchar(255)
NOT NULL,
131
TanggalReview datetime
NOT NULL,
IdMeja
NOT NULL,
char(3)
PRIMARY KEY (`IdReview`),
FOREIGN
KEY
(`IdMeja`)
REFERENCES
`Meja`
(`IdMeja`) ON DELETE CASCADE ON UPDATE
CASCADE,
);
11. User
Username
: Tipe Data karakter, length 10
Password
: Tipe Data karakter, length 32
HakAkses
: Tipe Data Integer, length 1
IdPegawai
: Tipe Data karakter, length 5
CREATE TABLE LaporanPemasukan (
Username
char(10)
NOT NULL,
Password
char(32)
NOT NULL,
HakAkses
int(1)
NOT NULL,
IdPegawai
char(5)
NOT NULL,
PRIMARY KEY (`Username`),
FOREIGN KEY (`IdPegawai`) REFERENCES `Pegawai`
(`IdPegawai`) ON DELETE CASCADE ON UPDATE
CASCADE
132
);
3.6.3.1.2 Merancang Representasi Data Yang Diturunkan
Derived data adalah data – data berupa hasil kalkulasi
yang dihilangkan pada tahap normalisasi (dari UNF menjadi
1NF). Namun data – data kalkulasi sebenarnya masih
dibutuhkan untuk kebutuhan basis data, tetapi tidak secara
langsung dibuatkan field (atribut) permanen dalam basis data
untuk menyimpan data – data tersebut, dan oleh karena itu
data – data tersebut diturunkan menjadi derived data. Data
yang diturunkan (derived data) dalam entitas – entitas berikut
:
1. Pembayaran dengan menampilkan Total
2. Pesanan dengan menampilkan Total Harga
3.6.3.1.3 Merancang Batasan – Batasan Umum
Tahap ini bertujuan untuk merancang constraint pada
DBMS yang digunakan. Constraint yang digunakan meliputi :
1.
Membatasi bahwa hanya terdapat Jenis Kelamin ‘P’
untuk Pria atau ‘W’ untuk Wanita yang terdapat pada
entitas
Pegawai.
CONSTRAINT
CHECK
dan
IN
digunakan pada atribut JenisKelamin. Perintah SQL –nya
sebagai berikut :
133
CHECK ( JenisKelamin IN (‘P’, ‘W’)).
3.6.3.2 Merancang Organisasi File dan Indeks
Tahapan ini bertujuan untuk merancang organisasi file dan
indeks yang digunakan dalm perancangan basis data fisikal. Pada
tahapan ini pula akan dijelaskan mengenai analisis transaksi dan
perkiraan kebutuhan ukuran disk space pada DBMS target.
3.6.3.2.1 Menganalisis Transaksi
Analisis
transaksi
ini
bertujuan
untuk
memahami fungsionalitas dari transaksi yang dapat
terjadi dari basis data fisikal. Transaksi – transaksi
yang dapat terjadi adalah sebagai berikut :
a.
Menambah, mengubah dan menghapus data
pegawai
b.
Melihat data pegawai
c.
Menambah, mengubah dan menghapus data
meja
d.
Melihat data meja
e.
Menambah, mengubah data pembayaran
f.
Melihat data pembayaran
g.
Menambah, mengubah dan menghapus data
pesanan
h.
Melihat data pesanan
134
i.
Menambah, mengubah dan menghapus data
review
j.
Melihat data review
k.
Menambah, mengubah dan menghapus stok
bahan makanan
l.
Melihat data stok bahan makanan
m.
Menambah, mengubah dan menghapus data
menu makanan detail
n.
Melihat data menu makanan detail
o.
Menambah, mengubah dan menghapus data
menu makanan
p.
Melihat data menu makanan
q.
Menambah, mengubah dan menghapus data
pesanan detail
r.
Melihat data pesanan detail
s.
Menambah, mengubah dan menghapus data
kategori makanan
t.
Melihat data kategori makanan
u.
Menambah, mengubah dan menghapus data
user
v.
Melihat data user
135
Tabel 3.7 Analisis Transaksi Pegawai dan Meja
Transaksi / Relasi
a
I
Pegawai
c
U D R I U D R I
X X X
Meja
b
d
U D R I U D R
X
X X X
Pembayaran
Pesanan
Review
StokBahanMakanan
MenuMakananDetail
MenuMakanan
PesananDetail
KategoriMakanan
User
Tabel 3.8 Analisis Transaksi Pembayaran dan Pesanan
X
136
Transaksi / Relasi
e
I
f
g
U D R I U D R I
h
U D R I U D R
Pegawai
Meja
X
Pembayaran
X
X X
X
Pesanan
X
X X X
X
Review
StokBahanMakanan
MenuMakananDetail
MenuMakanan
X
PesananDetail
X
KategoriMakanan
User
Tabel 3.9 Analisis Transaksi Review dan StokBahanMakanan
Transaksi / Relasi
i
I
J
k
U D R I U D R I
l
U D R I U D R
Pegawai
Meja
X
X
Pembayaran
Pesanan
Review
StokBahanMakanan
X X X
X
X X X
X
137
MenuMakananDetail
MenuMakanan
PesananDetail
KategoriMakanan
User
Tabel 3.10 Analisis Transaksi MenuMakananDetail dan MenuMakanan
Transaksi / Relasi
m
I
n
o
U D R I U D R I
p
U D R I U D R
Pegawai
Meja
Pembayaran
Pesanan
Review
StokBahanMakanan
MenuMakananDetail
MenuMakanan
X X X
X
X
X X X
PesananDetail
KategoriMakanan
User
Tabel 3.11 Analisis Transaksi PesananDetail dan KategoriMakanan
X
138
Transaksi / Relasi
q
I
R
s
U D R I U D R I
t
U D R I U D R
Pegawai
Meja
X
X
X
X
Pembayaran
Pesanan
Review
StokBahanMakanan
MenuMakananDetail
MenuMakanan
PesananDetail
KategoriMakanan
User
X
X X X
X
X X X
X
139
Tabel 3.12 Analisis Transaksi User
Transaksi / Relasi
U
I
v
U D R I U D R
Pegawai
X
X
Meja
Pembayaran
Pesanan
Review
StokBahanMakanan
MenuMakananDetail
MenuMakanan
PesananDetail
KategoriMakanan
User
X X X
X
Ketereangan :
•
‘I’ merupakan kepanjangan dari Insert, yang berarti user dapat
menambah data.
140
•
‘U’ merupakan kepanjangan dari Update, yang berarti user dapat
mengubah data.
•
‘D’ merupakan kepanjangan dari Delete, yang berarti user dapat
menghapus data.
•
‘R’ merupakan kepanjangan dari Read, yang berarti user hanya dapat
membuka dan tidak dapat memodifikasi data.
3.6.3.2.2 Memilih Organisasi File
DBMS yang digunakan dalam perancangan
basis data adalah MySQL dan organisasi file yang
dipilih adalah organisasi file dengan tipe struktur data
relational (hubungan).
3.6.3.2.3 Memilih Indeks
Tahap ini bertujuan untuk meningkatkan
perfoma sistem pada aplikasi. Pemilihan indeks
didasarkan pada atribut yang paling sering digunakan
dan yang paling banyak mengakses suatu record dalam
relasi yang ada sehingga memudahkan saat terjadinya
proses sorting (pengurutan) dan searching (pencarian)
data.
141
Berikut
adalah
rancangan
indeks
yang
digunakan pada entitas – entitas yang terdapat pada
basis data.
Tabel 3.13 Perancangan Indeks
Tabel
Indeks
Pegawai
idpegawai
Meja
idmeja
Pembayaran
idpembayaran
idpegawai
idpesanan
Pesanan
idpesanan
idmeja
Review
idreview
idmeja
StokBahanMakanan
Idstok
idpegawai
MenuMakananDetail
idmenu
idstok
MenuMakanan
idmenu
142
idkategorimakanan
PesananDetail
idmenu
idpesanan
KategoriMakanan
idkategorimakanan
User
username
idpegawai
3.6.3.2.4 Memperkirakan Kebutuhan Disk Space
Tujuan
dari
adanya
perkiraan
(estimasi)
kebutuhan ukuran disk space adalah untuk mengetahui
seberapa banyak kapasitas yang dibutuhkan untuk
menyimpan data dalam basis data (database). Hal ini
diperlukan untuk menentukan besarnya kapasitas yang
diperlukan untuk beberapa tahun kedepan.
Estimasi dapat dilakukan dengan melakukan
perhitungan besar tipe data pada DBMS yang
diinginkan.
143
Tabel 3.14 Estimasi Tabel Pegawai
Ukuran
Nama Entitas
Nama Atribut
Tipe Data
(Bytes)
Pegawai
IdPegawai
Karakter
5
NamaPegawai
Variasi
30
Karakter
Jabatan
Variasi
20
Karakter
JenisKelamin
Karakter
1
TanggalLahir
Date
8
Alamat
Variasi
200
Karakter
NomorHP
Variasi
16
Karakter
Total
280 byte
144
Kapasitas dari table pegawai adalah 280 byte
Data yang ada saat ini 13 pegawai, total penggunaan tabel
pegawai = 13 * 280 = 3640 byte
Diperkirakan dalam 1 tahun terjadi penambahan pegawai
sebanyak 10
Dalam waktu 5 tahun pertumbuhan dari table pegawai adalah
10 * 5 * 280 = 14000 byte
Sehingga total pertumbuhan tabel pegawai selama 5 tahun
ditambah data awal = 14000 + 3640 = 17640 byte
Tabel 3.15 Estimasi Tabel Meja
Nama
Nama
Ukuran
Tipe Data
Entitas
Atribut
Meja
IdMeja
NamaMeja
(Bytes)
Karakter
3
Variasi
10
Karakter
Username
Variasi
10
Karakter
Password
Variasi
5
Karakter
Status
Integer
4
145
Total
32 byte
Kapasitas dari table meja adalah 32 byte
Data yang ada saat ini 25 meja, total penggunaan tabel
meja = 25 * 32 = 800 byte
Diperkirakan dalam 1 tahun terjadi penambahan meja
sebanyak 10
Dalam waktu 5 tahun pertumbuhan dari table meja adalah
10 * 5 * 32 = 1600 byte
Sehingga total pertumbuhan tabel meja selama 5 tahun
ditambah data awal = 1600 + 800 = 2400 byte
Tabel 3.16 Estimasi Tabel Pembayaran
Nama
Tipe
Ukuran
Data
(Bytes)
Karakter
5
TanggalPembayaran Datetime
8
JumlahPembayaran
Int
4
IdPesanan
Karakter
5
IdPegawai
Karakter
5
Nama Atribut
Entitas
Pembayaran
IdPembayaran
Total
27 byte
Kapasitas dari table pembayaran adalah 27 byte
Data yang ada saat ini 10 pembayaran, total penggunaan
tabel pembayaran = 10 * 27 = 270 byte
146
Diperkirakan dalam 1 bulan terjadi penambahan transaksi
(pembayaran) sebanyak 600
Dalam waktu 1 tahun pertumbuhan dari tabel pembayaran
adalah 600 * 12 * 27 = 194400 byte
Dalam waktu 5 tahun pertumbuhan dari table pembayaran
adalah 5 * 194400 = 972000 byte
Sehingga total pertumbuhan tabel pembayaran selama 5
tahun ditambah data awal = 972000 + 270 = 972270 byte
Tabel 3.17 Estimasi Tabel Pesanan
Ukuran
Nama
Nama Atribut
Tipe Data
Entitas
Pesanan
(Bytes)
IdPesanan
Karakter
5
TanggalPesan
Datetime
8
StatusPesanan
Integer
4
IdMeja
Karakter
3
Total
20 byte
Kapasitas dari table pesanan adalah 20 byte
Data yang ada saat ini 10 pesanan, total penggunaan tabel
pesanan = 10 * 20 = 200 byte
Diperkirakan dalam 1 bulan terjadi transaksi pemesanan
sebanyak 600
Dalam waktu 1 tahun pertumbuhan dari table pesanan
147
adalah 600 * 12 * 20 = 144000 byte
Dalam waktu 5 tahun pertumbuhan dari table pesanan
adalah 5 * 144000 = 720000 byte
Sehingga total pertumbuhan tabel pesanan selama 5 tahun
ditambah data awal = 720000 + 200 = 720200 byte
Tabel 3.18 Estimasi Tabel PesananDetail
Ukuran
Nama Entitas
Nama Atribut
Tipe Data
(Bytes)
PesananDetail
IdMenu
Karakter
5
IdPesanan
Karakter
5
Qty
Integer
4
HargaSatuan
Integer
4
bumbu
Variasi
50
Karakter
catatan
Variasi
255
Karakter
Status
Integer
Total
Kapasitas dari table pesanandetail adalah 327 byte
4
327 byte
148
Data yang ada saat ini 25 pesanan detail, total penggunaan
tabel pesanandetail = 10 * 25 = 250 byte
Diperkirakan dalam 1 bulan terjadi transaksi pemesanan
sebanyak 600
Dalam waktu 1 tahun pertumbuhan dari table pesanan adalah
600 * 12 * 327 = 5297400 byte
Dalam waktu 5 tahun pertumbuhan dari table pesanan adalah
5 * 5297400 = 26487000 byte
Sehingga total pertumbuhan tabel pesanandetail selama 5
tahun ditambah data awal = 26487000 + 250 = 26487250
byte
Tabel 3.19 Estimasi Tabel MenuMakanan
Nama Entitas
MenuMakanan
Tipe
Ukuran
Data
(Bytes)
IdMenu
Karakter
5
NamaMenu
Variasi
100
Nama Atribut
Karakter
Harga
Integer
4
Deskripsi
Variasi
100
Karakter
NamaGambar
Variasi
Karakter
50
149
IdKategoriMakanan
Karakter
Total
3
262 byte
Kapasitas dari table menumakanan adalah 262 byte
Data yang ada saat ini 80 menu makanan, total penggunaan
tabel menumakanan = 80 * 262 = 20960 byte
Dalam waktu 1 tahun penambahan menumakanan sebanyak
10
Dalam waktu 5 tahun pertumbuhan dari table menumakanan
adalah 5 * 10 * 262 = 13100 byte
Sehingga total pertumbuhan tabel menumakanan selama 5
tahun ditambah data awal = 13100 + 20960 = 34060 byte
Tabel 3.20 Estimasi Tabel MenuMakananDetail
Ukuran
Nama Entitas
Nama Atribut
Tipe Data
(Bytes)
MenuDetail
IdMenu
Karakter
5
IdStok
Karakter
5
Qty
Variasi
25
Karakter
Total
35 byte
Kapasitas dari table menudetail adalah 35 byte (tiap 1 menu)
Data yang ada saat ini 150 menu makanan detail, total
150
penggunaan tabel menumakanandetail = 150 * 35 = 5250
byte
Dalam waktu 1 tahun penambahan menudetail sebanyak 20
Dalam waktu 5 tahun pertumbuhan dari table menudetail
adalah 5 * 20 * 35 = 3500 byte
Sehingga total pertumbuhan tabel menumakanandetail
selama 5 tahun ditambah data awal = 3500 + 5250 = 8750
byte
Tabel 3.21 Estimasi Tabel StokBahanMakanan
Ukura
Tipe
Nama Entitas
Nama Atribut
n
Data
(Bytes)
StokBahanMakana
IdStok
n
Karakte
5
r
NamaBahan
Variasi
25
Karakte
r
SatuanUkuranTota
Variasi
l
Karakte
6
r
Harga
Integer
4
MinimumStok
Integer
4
151
SatuanUkurMin
Variasi
10
Karakte
r
JumlahStok
Integer
4
TanggalMasuk
Date
8
IdPegawai
Karakte
5
r
catatan
Variasi
255
Karakte
r
Total
326
byte
Kapasitas dari table stokbahanmakanan adalah 326 byte
Data yang ada saat ini 120 stok bahan makanan, total
penggunaan tabel stokbahanmakanan = 120 * 326 = 39120
byte
Diperkirakan dalam 1 bulan terjadi penambahan stok
sebanyak 2
Dalam
waktu
1
tahun
pertumbuhan
dari
table
stokbahanmakanan adalah 2 * 12 * 326 = 7824 byte
Dalam
waktu
5
tahun
pertumbuhan
dari
table
stokbahanmakanan adalah 5 * 7824 = 39120 byte
Sehingga total pertumbuhan tabel stokbahanmakanan selama
152
5 tahun ditambah data awal = 39120 + 39120 = 78240 byte
Tabel 3.22 Estimasi Tabel Review
Nama Entitas
Review
Tipe
Ukuran
Data
(Bytes)
IdReview
Karakter
5
Review
Variasi
255
Nama Atribut
Karakter
TanggalReview
Datetime
8
IdMeja
Karakter
3
Total
271 byte
Kapasitas dari table review adalah 271 byte
Data yang ada saat ini 10 review, total penggunaan tabel
review = 10 * 271 = 2710 byte
Diperkirakan dalam 1 bulan terjadi penambahan review
sebanyak 450
153
Dalam waktu 1 tahun pertumbuhan dari table review adalah
450 * 12 * 271 = 1463400 byte
Dalam waktu 5 tahun pertumbuhan dari table review adalah
5 * 1463400 = 7317000 byte
Sehingga total pertumbuhan tabel review selama 5 tahun
ditambah data awal = 7317000 + 2710 = 7319710 byte
Tabel 3.23 Estimasi Tabel KategoriMakanan
Nama Entitas
KategoriMakanan
Tipe
Ukuran
Data
(Bytes)
Nama Atribut
IdKategoriMakanan Karakter
3
KategoriMakanan
50
Variasi
Karakter
Total
53 byte
Kapasitas dari table kategorimakanan adalah 53 byte
Data yang ada saat ini 15 kategori makanan, total
penggunaan tabel kategorimakanan = 15 * 53 = 795 byte
Diperkirakan dalam 1 tahun terjadi penambahan kategori
makanan sebanyak 10
Dalam
waktu
1
tahun
pertumbuhan
kategorimakanan adalah 10 * 53 = 530 byte
dari
table
154
Dalam
waktu
5
tahun
pertumbuhan
dari
table
kategorimakanan adalah 5 * 530 = 2650 byte
Sehingga total pertumbuhan tabel review selama 5 tahun
ditambah data awal = 2650 + 795 = 3445 byte
Tabel 3.24 Estimasi Tabel User
Nama Entitas
User
Tipe
Ukuran
Data
(Bytes)
Username
Karakter
10
Password
Karakter
32
HakAkses
Integer
4
IdPegawai
Karakter
5
Nama Atribut
Total
51 byte
Kapasitas dari table user adalah 51 byte
Data yang ada saat ini 4 user, total penggunaan tabel user =
4 * 51 = 204 byte
Diperkirakan dalam 1 tahun terjadi penambahan user
sebanyak 10
Dalam waktu 1 tahun pertumbuhan dari table user adalah 10
155
* 51 = 510 byte
Dalam waktu 5 tahun pertumbuhan dari table user adalah 5 *
510 = 2550 byte
Sehingga total pertumbuhan tabel user selama 5 tahun
ditambah data awal = 2550 + 204 = 2754 byte
3.6.3.3 Merancang Mekanisme Keamanan
Mekanisme keamanan sistem yang digunakan adalah
meliputi
penggunaan
Username
dan
Password
sebagai
identifikator user yang akan menjaga keamanan basis data.
Username dan Password disimpan dalam entitas User. Admin
memiliki hak akses tertinggi dalam sistem basis data, dan user –
user lain selain admin masing – masing memiliki kode jabatan
yang diberi hak akses dalam batasan tertentu. Hal ini dilakukan
untuk menjaga keamanan dan integritas data dari sistem basis data
Restoran Raja Kepiting.
156
3.7
Perancangan Aplikasi
Tahap dimana aplikasi dirancang dan terdiri dari 3 tahap yaitu
perancangan struktur menu, STD, dan rancangan layar input/output.
3.7.1
Perancangan Struktur Menu
Berikut ini adalah struktur menu dari aplikasi yang akan dirancang :
157
Gambar 3.32 Struktur Menu Admin
Gambar 3.33 Struktur Menu User
158
3.7.2
State Transition Diagran (STD)
Berikut ini adalah State Transition Diagram (STD) dari aplikasi yang
akan dirancang :
Gambar 3.34 STD Login
159
Gambar 3.35 STD Menu Utama Admin
Gambar 3.36 STD Admin Menu Makanan
160
Gambar 3.37 STD Admin Menu Stok
Gambar 3.38 STD Admin Menu Pegawai
161
Gambar 3.39 STD Admin Menu User
Gambar 3.40 STD Admin Menu Meja
162
Gambar 3.41 STD Admin Menu Kategori Makanan
Gambar 3.42 STD Admin Menu Laporan Pemasukan
163
Gambar 3.43 STD Admin Menu Pembayaran
164
Gambar 3.44 STD Menu Utama User
Gambar 3.45 STD Order
165
Form Checkout
Klik “Checkout”
Tambahkan Data Order
Tambahkan Data Order
Klik “Simpan”
Data Order tidak lengkap,
Tambahkan Pesan Error
Pesan Error
Klik “Ubah”
Ubah Data Order
Ubah Data Order
Klik “Hapus”
Hapus Data Order
Hapus Data Order
Gambar 3.46 STD Checkout
Gambar 3.47 STD Menu Testimoni
3.7.3
Rancangan Layar Input/Output
Pada sub bab ini akan dilakukan perancangan layar input maupun output
yang akan dibuat pada aplikasi. Rancangan layar ini terdiri dari rancangan layar
untuk admin dan juga untuk pelanggan.
a. Perancangan Layar Login Pelanggan
166
Halaman ini merupakan halaman pertama ketika pelanggan akan
melakukan login. Pada halaman ini pelanggan harus memasukkan
username dan password yang dimilikinya. Untuk pelanggan, username dan
password akan diberikan oleh kasir agar dapat melakukan pemesanan
makanan.
Gambar 3.48 Rancangan Layar Login untuk Pelanggan
b. Perancangan Layar Pelanggan Menu Home
Halaman ini merupakan halaman ketika seorang pelanggan berhasil login
pada sistem aplikasi. Pada halaman ini akan ditampilkan menu – menu
makanan yang tersedia di Restoran Raja kepiting.
167
Gambar 3.49 Rancangan Layar Menu Home untuk Pelanggan
c. Perancangan Layar Pelanggan Menu Tagihan
Pada halaman ini akan berisi tagihan atas menu makanan yang telah
dipesan oleh pelanggan.
168
Gambar 3.50 Rancangan Layar Menu Tagihan untuk Pelanggan
d. Perancangan Layar Pelanggan Menu Testimoni
Pada halaman ini pelanggan dapat memberikan saran / komentar terhadap
pelayanan di Restoran Raja Kepiting. Halaman ini bersifat optional, yang
berarti pelanggan dapat memberikan saran / komentar terhadap pelayanan
yang diberikan ataupun tidak. Pelanggan dapat memberikan saran /
komentar di bagian textarea lalu menekan tombol button yang telah
disediakan.
169
Gambar 3.51 Rancangan Layar Menu Testimoni untuk Pelanggan
e. Perancangan Layar Login Admin
Merupakan rancangan layar untuk login admin, pada rancangan layar ini
disediakan textbox yang nantinya digunakan admin untuk memasukkan
username dan password yang dimilikinya untuk dapat mengakses halaman
admin. Pada bagian header nanti akan diletakkan logo dari restoran.
170
Gambar 3.52 Rancangan Layar Login Admin
f. Perancangan Layar Admin Menu Home
Pada rancangan layar ini, di bagian “List of Tables” akan berisi meja – meja
yang akan digunakan pada Restoran Raja Kepiting. Di bagian sebelah kiri
akan digunakan untuk melakukan generate password yang nantinya akan
digunakan oleh pelanggan untuk memesan makanan.
171
Gambar 3.53 Rancangan Layar Menu Home untuk Admin
g. Perancangan Layar Admin Menu “Menu Makanan”
Pada halaman ini akan berisi daftar menu makanan yang berada di Restoran
Raja Kepiting. Menu – menu tersebut nantinya dapat dilakukan perubahan
maupun dihapus dari daftar menu makanan di Restoran Raja Kepiting. Di
bagian sebelah kiri akan dibuatkan form yang nantinya digunakan untuk
menambah atau mengubah menu makanan.
172
Gambar 3.54 Rancangan Layar Menu “Menu Makanan” untuk Admin
h. Perancangan Layar Admin Menu Stok
Pada halaman ini akan berisi daftar stok yang digunakan di Restoran Raja
Kepiting. Daftar stok tersebut nantinya dapat dilakukan perubahan maupun
dihapus dari daftar stok yang ada di Restoran Raja Kepiting. Di bagian
sebelah kiri akan dibuatkan form yang nantinya digunakan untuk
menambah atau mengubah stok.
173
Gambar 3.55 Rancangan Layar Menu Stok untuk Admin
i. Perancangan Layar Admin Menu Pegawai
Berisi daftar pegawai yang bekerja di Restoran Raja Kepiting. Pada layar
ini nantinya akan ditampilkan nama pegawai, jabatan, gender, nomor HP,
dan action dimana dapat dilakukan perubahan data pegawai ataupun
dilakukan penghapusan data pegawai, nantinya akan disediakan pula form
untuk menambah pegawai baru.
174
Gambar 3.56 Rancangan Layar Menu Pegawai untuk Admin
j. Perancangan Layar Admin Menu User
Pada halaman ini nantinya akan ditampilkan pegawai – pegawai yang
memiliki hak khusus, dimana user tersebut dapat melakukan perubahan
terhadap sistem aplikasi ini. Disediakan pula form untuk menambahkan
user baru yang terletak disebelah kiri layar.
175
Gambar 3.57 Rancangan Layar Menu User untuk Admin
k. Perancangan Layar Admin Menu Meja
Pada layar ini akan berisi meja – meja yang dapat digunakan pelanggan
sebagai username yang nantinya digunakan untuk login sistem. Di halaman
ini akan terdapat nama meja, username, password dan action yang dapat
digunakan untuk mengubah atau menghapus data meja. Di sebelah kiri juga
disediakan form untuk menambah meja, jika jumlah meja yang ada
sekarang dianggap kurang cukup.
176
Gambar 3.58 Rancangan Layar Menu Meja untuk Admin
l. Perancangan Layar Admin Menu Kategori Makanan
Berisi Kategori Makanan yang digunakan oleh Restoran Raja Kepiting.
Dalam rancangan ini akan ditampilkan nama kategori makanan dan juga
action yang digunakan untuk mengubah atau menghapus data kategori
makanan. Disediakan pula form untuk menambahkan kategori makanan
baru yang terletak di sebelah kiri layar.
177
Gambar 3.59 Rancangan Layar Menu Kategori Makanan untuk Admin
m. Perancangan Layar Admin Menu Laporan
Pada rancangan ini akan dibuat menu laporan yang terdiri dari 3 bagian,
yaitu laporan per hari, laporan per bulan dan laporan per tahun. Pada
rancangan layar akan ditampilkan no order, nomor meja, waktu pesan,
detail pesanan dan juga total tiap nomor order.
178
Gambar 3.60 Rancangan Layar Menu Laporan untuk Admin
n. Perancangan Layar Admin Menu Transaksi
Pada rancangan layar ini, akan berisi transaksi yang terjadi ketika
terjadinya pemesanan makanan oleh para pelanggan. Pada rancangan ini
akan ditampilkan nomor meja, nama menu jumlah menu yang dipesan,
serta catatan dari menu yang dipesan.
179
Gambar 3.61 Rancangan Layar Menu Transaksi untuk Admin
o. Perancangan Layar Admin Menu Pembayaran
Berisi nomor meja dari pelanggan yang memesan makanan, dimana dari
nomor meja tersebut dapat dilihat nama menu yang dipesan, jumlah menu
yang dipesan, harga satuan menu, dan total harga dari nomor meja tersebut.
Pada layar ini juga disediakan button, untuk melakukan penghitungan,
simpan dan simpan dan cetak.
180
Gambar 3.62 Rancangan Layar Menu Pembayaran untuk Admin