BAB III ANALISA DAN PERANCANGAN. wewenang dan tanggung jawab dari masing masing bagian pekerjaan. No. 35 Serpong (Depan WTC Matahari)

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


JenisKelamin

Sebuah karakter ‘M’ untuk jenis kelamin laki-laki atau ‘F’ untuk jenis kelamin perempuan

Meja

TanggalLahir

Tanggal dengan format dd-mm-yyyy

Alamat


NomorHP


IdMeja

5 karakter dengan format Cxxxx, dimana karakter ‘C’ merupakan kode pelanggan dan empat karakter berikutnya merupakan nomor pelanggan

Pesanan

NamaMeja


Username


Password


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


JumlahPesanan Angka bulat (non-desimal)

MenuMakanan

Harga


TotalHarga


TanggalPesan


StatusPesanan


IdMenu

5 karakter dengan format Mxxxx, dimana karakter ‘M’ merupakan kode menu makanan dan empat karakter berikutnya merupakan nomor dari menu makanan tersebut

NamaMenu


Harga


Deskripsi


StokBahanMaka IdStok

5 karakter dengan format Sxxxx, dimana karakter ‘S’

nan

merupakan kode stok dan empat karakter berikutnya merupakan nomor stok NamaBahan


SatuanUkuran


HargaSatuanU


kuran MinimumStok


JumlahStok


92

Pembayaran

TanggalMasuk


IdPembayaran

5 karakter dengan format Pxxxx, dimana karakter ‘P’ merupakan kode untuk pembayaran dan empat karakter berikutnya merupakan nomor transaksi pembayaran

TotalHarga


JumlahPembay


aran JumlahUangKe Angka bulat (non-desimal) mbali TanggalPemba


yaran Review

IdReview

5 karakter dengan format Fxxxx, dimana karakter ‘F’ merupakan kode untuk review / feedback dan empat karakter berikutnya merupakan nomor review

Review


Tanggal


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


JenisKelamin

: Tipe Data karakter, length 1 harus ‘M’ atau ‘F’

TanggalLahir

: Tipe Data date

Alamat


NomorHP


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 (ÌdPegawai`) );

2. Meja Keterangan: IdMeja


NamaMeja


UserName


Password


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 (ÌdMeja`)

124

); 3. Pembayaran Keterangan: IdPembayaran


TanggalPembayaran

: Tipe Data datetime

JumlahPembayaran


Idpesanan


IdPegawai


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 (Ìdpembayaran`), FOREIGN KEY (ÌdPesanan`) REFERENCES Pesanan (ÌdPesanan`) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (ÌdPegawai`) REFERENCES Pegawai (ÌdPegawai`) ON DELETE CASCADE ON UPDATE CASCADE );

125

4. Pesanan Keterangan: IdPesanan


TanggalPesan

: Tipe Data datetime,

StatusPesanan

: Tipe Data Integer, length 1

IdMeja


CREATE TABLE Pesanan ( IdPesanan

char(5)

NOT NULL,

TanggalPesan

date

NOT NULL,

StatusPesanan

int(1)

NOT NULL,

IdMeja

char(3)

NOT NULL,

PRIMARY KEY (ÌdPesanan`), FOREIGN

KEY

(ÌdMeja`)

REFERENCES

`Meja`

(ÌdMeja`) ON DELETE CASCADE ON UPDATE CASCADE );

5. PesananDetail Keterangan: IdMenu


IdPesanan


Qty


126

HargaSatuan


Bumbu


Catatan


Status


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 (ÌdMenu`,ÌdPesanan`), FOREIGN

KEY

(ÌdMenu`)

REFERENCES

`MenuMakanan` (ÌdMenu`) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (ÌdPesanan`) REFERENCES `Pesanan` (ÌdPesanan`) ON DELETE CASCADE ON UPDATE CASCADE );

127

6. KategoriMakanan Keterangan: IdKategoriMakanan


KategoriMakanan


CREATE TABLE KategoriMakanan ( IdKategoriMakanan

char(3)

NOT NULL,

KategoriMakanan

char(50)

NOT NULL,

PRIMARY KEY (ÌdKategoriMakanan`) );

7. MenuMakanan Keterangan: IdMenu


NamaMenu


Harga


Deskripsi


NamaGambar


IdKategoriMakanan


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 (ÌdMenu`), FOREIGN KEY (ÌdKategoriMakanan`) REFERENCES `KategoriMakanan` (ÌdKategoriMakanan`) ON DELETE CASCADE ON UPDATE CASCADE );

8. MenuDetail Keterangan: IdMenu


IdStok


Qty


CREATE TABLE MenuDetail ( IdMenu

char(5)

NOT NULL,

IdStok

char(5)

NOT NULL,

Qty

varchar(25)

NOT NULL,

129

PRIMARY KEY (ÌdMenu`,ÌdStok`), FOREIGN

KEY

(ÌdMenu`)

REFERENCES

`MenuMakanan` (ÌdMenu`) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN

KEY

`StokBahanMakanan`

(ÌdStok`) (ÌdStok`)

REFERENCES ON

DELETE

CASCADE ON UPDATE CASCADE );

9. StokBahanMakanan Keterangan: IdStok


NamaBahan


SatuanUkuranTotal


Harga


MinimumStok


SatuanUkurMin


JumlahStok


TanggalMasuk

: Tipe Data date

IdPegawai


Catatan


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 (ÌdStok`), FOREIGN KEY (ÌdPegawai`) REFERENCES `Pegawai` (ÌdPegawai`) ON DELETE CASCADE ON UPDATE CASCADE ); 10. Review Keterangan: IdReview


Review


TanggalReview

: Tipe Data datetime,

IdMeja


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 (ÌdReview`), FOREIGN

KEY

(ÌdMeja`)

REFERENCES

`Meja`

(ÌdMeja`) ON DELETE CASCADE ON UPDATE CASCADE, );

11. User Username


Password


HakAkses

: Tipe Data Integer, length 1

IdPegawai


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 (Ùsername`), FOREIGN KEY (ÌdPegawai`) REFERENCES `Pegawai` (ÌdPegawai`) 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


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


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


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

BAB III ANALISA DAN PERANCANGAN. wewenang dan tanggung jawab dari masing masing bagian pekerjaan. No. 35 Serpong (Depan WTC Matahari)

Recommend Documents