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

114  Download (0)

Teks penuh

(1)

67 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

(2)

(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 tindakan-tindakan dalam mencapai tujuan umum perusahaan.

(3)

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.

(4)

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:

(5)

- 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 :

- Bertugas untuk melayani tamu restoran

- Bertugas menyajikan makanan dan minuman untuk tamu - Bertugas sebagai penerima pesanan makanan dan minuman

3.2 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).

(6)

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

(7)

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 :

(8)

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 :

(9)

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.

(10)

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.

(11)

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.

(12)

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.

(13)

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

(14)

3.5.2 Diagram Nol

(15)

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.

(16)

Tabel 3.1 Identifikasi Tipe Entitas

No Entitas Deskripsi Alias Occurrence

1

Pegawai Orang-orang

yang berkerja di perusahaan

Employee Setiap pegawai bekerja pada satu bidang tertentu 2 Meja Perlengkapan yang digunakan sebagai tempat makan untuk pelanggan Table Setiap pelanggan memiliki satu meja makan 3 Pesanan Menggambarkan pesanan produk yang dilakukan pelanggan

Order Setiap pesanan yang dilakukan oleh pelanggan

4

MenuMakanan Menggambarkan hasil dari bahan baku yang telah di proses menjadi makanan

Produk Setiap menu makanan yang dihasilkan dari proses produksi 5 StokBahanMakanan Menggambarkan bahan makanan yang digunakan Raw material Setiap bahan makanan yang ada di stok

(17)

untuk membuat produk 6 Pembayaran Menggambarkan proses pembayaran pesanan Payment Setiap pembayaran dilakukan jika pelanggan telah selesai makan 7 Review Mengambarkan proses feedback pelanggan terhadap makanan yang dimakan Review Review dilakukan jika pelanggan telah selesai makan

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 :

(18)

a. Perancangan ERD (Entity Relationship Diagram) Pesanan StokBahanMakanan MenuMakanan Meja Review Pegawai Pembayaran Melengkapi_Pesanan Memengaruhi_Stok Memengaruhi_Menu Memberikan_Saran_Komentar Melakukan_Pembayaran M el ak u k an _ P em es an an M en er im a_ P em b ay ar an Menghitung_Stok Menghasilkan_Pembayaran 1..1 0..1 1..* 1..1 1..1 0..* 1..1 0..* 1..1 0..* 1..* 1..* 1..* 1..* 1..* 1..* 1..1 1..1

(19)

b. Penentuan multiplicity dari hasil relasi Tabel 3.2 Identifikasi Tipe Relasi

Entitas Multiplicity Relationship Multiplicity Entitas

Pegawai 1..1 Menghitung_ Stok 0..* StokBahanMakanan 1..1 Menerima_Pe mbayaran 0..* Pembayaran Meja 1..1 Memberikan_ Saran_Komen tar 0..1 Review 1..1 Melakukan_P emesanan 1..* Pesanan 1..1 Melakaukan_ Pembayaran 0..* Pembayaran Pesanan 1..1 Menghasilkan _Pembayaran 1..1 Pembayaran MenuMakanan 1..* Melengkapi_P esanan 1..* Pesanan StokBahanMakanan 1..* Memengaruhi _Menu 1..* Menu Makanan 1..* Memengaruhi _Stok 1..* Pesanan

(20)

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

Entitas Atribut Deskripsi

Tipe Data & Panjang

NULL

Multi-valued

Pegawai IdPegawai Atribut unik untuk

identifikasi pegawai

Char (5) Tidak Tidak

NamaPegawai Nama pegawai Varchar(30) Tidak Tidak

Jabatan Jabatan pegawai Varchar (20) Tidak Tidak

JenisKelamin Jenis kelamin

pegawai

Char (1) Tidak Tidak

TanggalLahir Tanggal lahir

pegawai

Date Tidak Tidak

Alamat Alamat pegawai Varchar (200) Tidak Tidak

NomorHP Nomor HP

Pegawai

Varchar (16) Ya Tidak

Meja IdMeja Atribut unik untuk

identifikasi

(21)

pelanggan

NamaMeja Nomor meja

pelanggan

Varchar(10) Tidak Tidak

Username Username untuk

login aplikasi

Varchar (10) Tidak Tidak

Password Password untuk

login aplikasi

Varchar (5) Tidak Tidak

Status Status dari meja

tersebut

Int Tidak Tidak

Pesanan IdPesanan Atribut unik untuk

identifikasi pesanan makanan

Char (5) Tidak Tidak

NamaMenu Nama menu Varchar(100) Tidak Tidak

JumlahPesanan Jumlah pesanan

pelanggan

Int Tidak Tidak

Harga Harga satuan

menu makanan

Float Tidak Tidak

TotalHarga Total harga

keseluruhan pesanan pelanggan

Float Tidak Tidak

TanggalPesan Waktu pesanan

makanan

Date Tidak Tidak

StatusPesanan Status pesanan

makanan

Int Tidak Tidak

(22)

n identifikasi menu makanan

NamaMenu Nama menu

makanan

Varchar (30) Tidak Tidak

Harga Harga satuan

menu makanan

Float Tidak Tidak

Deskripsi Deskripsi dari

menu makanan

Varchar (100) Ya Tidak

StokBahanMa kanan

IdStok Atribut unik untuk

identifikasi stok bahan makanan

Char (5) Tidak Tidak

NamaBahan Nama bahan Varchar (15) Tidak Tidak

SatuanUkuran Satuan ukuran Varchar (6) Tidak Tidak

HargaSatuanUkuran Harga satuan

ukuran bahan

Float Tidak Tidak

MinimumStok Minimum stok Int Tidak Tidak

JumlahStok Jumlah stok yang

ada

Int Tidak Tidak

TanggalMasuk Tanggal masuk

bahan makanan

Date Tidak Tidak

Pembayaran IdPembayaran Atribut unik untuk

identifikasi pembayaran

Char (5) Tidak Tidak

TotalHarga Total harga

pesanan menu

(23)

makanan

JumlahPembayaran Jumlah

pembayaran yang diberikan

pelanggan

Float Tidak Tidak

JumlahUangKembali Jumlah uang

kembalian pelanggan

Float Tidak Tidak

TanggalPembayaran Tanggal

pembayaran

Date Tidak Tidak

Review IdReview Atribut unik untuk

identifikasi review

Char (5) Tidak Tidak

Review Isi review

pelanggan

Varchar (50) Tidak Tidak

Tanggal Tanggal pengisian

review

Date Tidak Tidak

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.

(24)

Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama.

Tabel 3.4 Determinasi Domain Atribut

Entitas Atribut Domain Atribut

Pegawai IdPegawai 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 TanggalLahir Tanggal dengan format dd-mm-yyyy

Alamat Variasi karakter dengan maksimal jumlah 100 karakter NomorHP Variasi karakter dengan maksimal jumlah 14 karakter Meja IdMeja 5 karakter dengan format Cxxxx, dimana karakter ‘C’

merupakan kode pelanggan dan empat karakter berikutnya merupakan nomor pelanggan

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)

(25)

merupakan kode pesanan dan empat karakter berikutnya merupakan nomor pesanan

NamaMenu Variasi karakter dengan maksimal jumlah 10 karakter JumlahPesanan Angka bulat (non-desimal)

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 MenuMakanan 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

nan

IdStok 5 karakter dengan format Sxxxx, dimana karakter ‘S’ 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

kuran

Angka bulat (non-desimal)

MinimumStok Angka bulat (non-desimal) JumlahStok Angka bulat (non-desimal)

(26)

TanggalMasuk Tanggal dengan format dd-mm-yyyy

Pembayaran 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 aran

Angka bulat (non-desimal)

JumlahUangKe mbali

Angka bulat (non-desimal)

TanggalPemba yaran

Tanggal dengan format dd-mm-yyyy

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

(27)

adalah key yang dipilih untuk mengidentifikasikan secara unik tiap kejadiandari tipe entitas.

Tabel 3.5 Identifikasi Candidate Key dan Primary Key

Entity Candidate Key Primary Key

Pegawai Idpegawai Namapegawai Alamat Nomorhp Idpegawai Meja IdMeja NamaMeja Username IdMeja Pesanan Idpesanan Namamenu Idpesanan MenuMakanan Idmenu Namamenu Idmenu StokBahanMakanan Idstok Namabahan Idstok

Pembayaran Idpembayaran Idpembayaran

(28)

Gambar 3.11 Entity Relationship Diagram tahap Konseptual dengan

(29)

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.

(30)

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

(31)

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

(32)

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

(33)

menghasilkan pembayaran antara Pesanan dan Pembayaran.

• Relasi akhir :

Gambar 3.17 Hubungan Akhir antara Pembayaran, Meja, dan Pesanan

(34)

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

(35)

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.

(36)

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

(37)

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 ( IdPegawai, NamaPegawai, Jabatan, JenisKelamin, TanggalLahir, Alamat, NomorHP, Username, Password )

Primary Key ( IdPegawai )

Meja ( IdMeja, NamaMeja, Username, Password, TanggalDatang, Pesanan, Status )

(38)

Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga, TotalHarga, TanggalPesan, StatusPesanan )

Primary Key ( IdPesanan )

MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi ) Primary Key ( IdMenu )

StokBahanMakanan ( IdStok, NamaBahan, SatuanUkuran, HargaSatuanUkuran, MinimumStok, JumlahStok, TanggalMasuk )

Primary Key ( IdStok )

Pembayaran ( IdPembayaran, TotalHarga, JumlahPembayaran, 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.

(39)

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 menjadi foreign key pada StokBahanMakanan untuk hubungan 1..* menghitung_stok antara Pegawai dan StokBahanMakanan.

(40)

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.

(41)

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.

(42)

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.

(43)

2. Tambahkan IdPesanan menjadi foreign key pada Pembayaran untuk relasi 1..1 yang menggunakan mandatory participation 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 *..* antara StokBahanMakanan dan MenuMakanan

(44)

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

(45)

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.

(46)

• 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

(47)

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 )

(48)

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 )

(49)

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 )

(50)

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 )

(51)
(52)

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

(53)

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

(54)

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

(55)

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.

(56)

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,

(57)

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`)

(58)

); 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

(59)

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

(60)

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

(61)

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

(62)

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,

(63)

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

);

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 (

(64)

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,

(65)

TanggalReview datetime NOT NULL,

IdMeja char(3) NOT NULL,

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

(66)

);

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 :

(67)

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

(68)

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

(69)

Tabel 3.7 Analisis Transaksi Pegawai dan Meja Transaksi / Relasi a b c d I U D R I U D R I U D R I U D R Pegawai X X X X Meja X X X X Pembayaran Pesanan Review StokBahanMakanan MenuMakananDetail MenuMakanan PesananDetail KategoriMakanan User

(70)

Transaksi / Relasi e f g h I U D R I U D R I U D R I U D R Pegawai Meja X X Pembayaran 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 J k l I U D R I U D R I U D R I U D R Pegawai Meja X X Pembayaran Pesanan Review X X X X StokBahanMakanan X X X X

(71)

MenuMakananDetail MenuMakanan PesananDetail KategoriMakanan User

Tabel 3.10 Analisis Transaksi MenuMakananDetail dan MenuMakanan

Transaksi / Relasi m n o p I U D R I U D R I U D R I U D R Pegawai Meja Pembayaran Pesanan Review StokBahanMakanan MenuMakananDetail X X X X MenuMakanan X X X X X PesananDetail KategoriMakanan User

(72)

Transaksi / Relasi q R s t I U D R I U D R I U D R I U D R Pegawai Meja X X Pembayaran Pesanan X X Review StokBahanMakanan MenuMakananDetail MenuMakanan X PesananDetail X X X X KategoriMakanan X X X X User

(73)

Tabel 3.12 Analisis Transaksi User Transaksi / Relasi U v I 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.

(74)

‘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.

(75)

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

(76)

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.

(77)

Tabel 3.14 Estimasi Tabel Pegawai

Nama Entitas Nama Atribut Tipe Data

Ukuran (Bytes)

Pegawai IdPegawai Karakter 5

NamaPegawai Variasi Karakter 30 Jabatan Variasi Karakter 20 JenisKelamin Karakter 1 TanggalLahir Date 8 Alamat Variasi Karakter 200 NomorHP Variasi Karakter 16 Total 280 byte

(78)

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 Entitas Nama Atribut Tipe Data Ukuran (Bytes)

Meja IdMeja Karakter 3

NamaMeja Variasi Karakter 10 Username Variasi Karakter 10 Password Variasi Karakter 5 Status Integer 4

(79)

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 Entitas Nama Atribut Tipe Data Ukuran (Bytes) Pembayaran IdPembayaran Karakter 5

TanggalPembayaran Datetime 8 JumlahPembayaran Int 4 IdPesanan Karakter 5 IdPegawai Karakter 5

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

(80)

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 Nama

Entitas

Nama Atribut Tipe Data

Ukuran (Bytes) Pesanan 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

(81)

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

Nama Entitas Nama Atribut Tipe Data

Ukuran (Bytes)

PesananDetail IdMenu Karakter 5

IdPesanan Karakter 5 Qty Integer 4 HargaSatuan Integer 4 bumbu Variasi Karakter 50 catatan Variasi Karakter 255 Status Integer 4 Total 327 byte

(82)

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 Nama Atribut

Tipe Data

Ukuran (Bytes)

MenuMakanan IdMenu Karakter 5

NamaMenu Variasi Karakter 100 Harga Integer 4 Deskripsi Variasi Karakter 100 NamaGambar Variasi Karakter 50

(83)

IdKategoriMakanan Karakter 3

Total 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

Nama Entitas Nama Atribut Tipe Data

Ukuran (Bytes)

MenuDetail IdMenu Karakter 5

IdStok Karakter 5

Qty Variasi

Karakter

25

Total 35 byte

Kapasitas dari table menudetail adalah 35 byte (tiap 1 menu) Data yang ada saat ini 150 menu makanan detail, total

(84)

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

Nama Entitas Nama Atribut

Tipe Data Ukura n (Bytes) StokBahanMakana n IdStok Karakte r 5 NamaBahan Variasi Karakte r 25 SatuanUkuranTota l Variasi Karakte r 6 Harga Integer 4 MinimumStok Integer 4

(85)

SatuanUkurMin Variasi Karakte r 10 JumlahStok Integer 4 TanggalMasuk Date 8 IdPegawai Karakte r 5 catatan Variasi Karakte r 255 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

(86)

5 tahun ditambah data awal = 39120 + 39120 = 78240 byte

Tabel 3.22 Estimasi Tabel Review

Nama Entitas Nama Atribut

Tipe Data

Ukuran (Bytes)

Review IdReview Karakter 5

Review Variasi Karakter 255 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

(87)

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 Nama Atribut

Tipe Data

Ukuran (Bytes) KategoriMakanan IdKategoriMakanan Karakter 3

KategoriMakanan Variasi Karakter

50

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 dari table kategorimakanan adalah 10 * 53 = 530 byte

(88)

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 Nama Atribut

Tipe Data

Ukuran (Bytes)

User Username Karakter 10

Password Karakter 32 HakAkses Integer 4 IdPegawai Karakter 5

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

(89)

* 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.

(90)

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

(91)

Gambar 3.32 Struktur Menu Admin

(92)

3.7.2 State Transition Diagran (STD)

Berikut ini adalah State Transition Diagram (STD) dari aplikasi yang akan dirancang :

(93)

Gambar 3.35 STD Menu Utama Admin

(94)

Gambar 3.37 STD Admin Menu Stok

(95)

Gambar 3.39 STD Admin Menu User

(96)

Gambar 3.41 STD Admin Menu Kategori Makanan

(97)
(98)

Gambar 3.44 STD Menu Utama User

(99)

Form Checkout

Tambahkan Data Order

Pesan Error

Ubah Data Order

Hapus Data Order Klik “Checkout”

Tambahkan Data Order

Klik “Simpan” Data Order tidak lengkap,

Tambahkan Pesan Error

Klik “Ubah” Ubah Data Order

Klik “Hapus” 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.

(100)

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.

(101)

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.

Figur

Gambar 3.6 Proses Bisnis Pembayaran Tagihan

Gambar 3.6

Proses Bisnis Pembayaran Tagihan p.10
Gambar 3.8 Diagram Konteks Sistem yang Diusulkan

Gambar 3.8

Diagram Konteks Sistem yang Diusulkan p.13
Gambar 3.9 Diagram Nol Sistem yang Diusulkan

Gambar 3.9

Diagram Nol Sistem yang Diusulkan p.14
Gambar 3.10 Entity Relationship Diagram tahap Konseptual

Gambar 3.10

Entity Relationship Diagram tahap Konseptual p.18
Gambar 3.11 Entity Relationship Diagram tahap Konseptual dengan

Gambar 3.11

Entity Relationship Diagram tahap Konseptual dengan p.28
Gambar 3.18 Entity Relationship Diagram Konseptual Setelah Penghilangan  Hubungan Redundansi

Gambar 3.18

Entity Relationship Diagram Konseptual Setelah Penghilangan Hubungan Redundansi p.34
Gambar 3.19 Validasi Model Konseptual dengan Transaksi Pengguna

Gambar 3.19

Validasi Model Konseptual dengan Transaksi Pengguna p.36
Gambar 3.30 Relasi Akhir many – to – many Antara MenuMakanan dan Pesanan

Gambar 3.30

Relasi Akhir many – to – many Antara MenuMakanan dan Pesanan p.46
Gambar 3.31 Entity Relationship Diagram Logikal

Gambar 3.31

Entity Relationship Diagram Logikal p.51
Tabel 3.7 Analisis Transaksi Pegawai dan Meja  Transaksi / Relasi  a  b  c  d  I  U  D  R  I  U  D  R  I  U  D  R  I  U  D  R  Pegawai  X  X  X    X    Meja  X  X  X    X  Pembayaran  Pesanan  Review  StokBahanMakanan  MenuMakananDetail  MenuMakanan  Pesan

Tabel 3.7

Analisis Transaksi Pegawai dan Meja Transaksi / Relasi a b c d I U D R I U D R I U D R I U D R Pegawai X X X X Meja X X X X Pembayaran Pesanan Review StokBahanMakanan MenuMakananDetail MenuMakanan Pesan p.69
Tabel 3.12 Analisis Transaksi User  Transaksi / Relasi  U  v  I  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 :

Tabel 3.12

Analisis Transaksi User Transaksi / Relasi U v I 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 : p.73
Tabel 3.14 Estimasi Tabel Pegawai

Tabel 3.14

Estimasi Tabel Pegawai p.77
Tabel 3.15 Estimasi Tabel Meja  Nama  Entitas  Nama  Atribut  Tipe Data  Ukuran (Bytes)

Tabel 3.15

Estimasi Tabel Meja Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) p.78
Tabel 3.16 Estimasi Tabel Pembayaran  Nama  Entitas  Nama Atribut  Tipe  Data  Ukuran (Bytes)  Pembayaran  IdPembayaran  Karakter  5

Tabel 3.16

Estimasi Tabel Pembayaran Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) Pembayaran IdPembayaran Karakter 5 p.79
Tabel 3.22 Estimasi Tabel Review

Tabel 3.22

Estimasi Tabel Review p.86
Gambar 3.35 STD Menu Utama Admin

Gambar 3.35

STD Menu Utama Admin p.93
Gambar 3.46 STD Checkout

Gambar 3.46

STD Checkout p.99
Gambar 3.48 Rancangan Layar Login untuk Pelanggan

Gambar 3.48

Rancangan Layar Login untuk Pelanggan p.100
Gambar 3.49 Rancangan Layar Menu Home untuk Pelanggan

Gambar 3.49

Rancangan Layar Menu Home untuk Pelanggan p.101
Gambar 3.50 Rancangan Layar Menu Tagihan untuk Pelanggan

Gambar 3.50

Rancangan Layar Menu Tagihan untuk Pelanggan p.102
Gambar 3.51 Rancangan Layar Menu Testimoni untuk Pelanggan

Gambar 3.51

Rancangan Layar Menu Testimoni untuk Pelanggan p.103
Gambar 3.52 Rancangan Layar Login Admin

Gambar 3.52

Rancangan Layar Login Admin p.104
Gambar 3.53 Rancangan Layar Menu Home untuk Admin

Gambar 3.53

Rancangan Layar Menu Home untuk Admin p.105
Gambar 3.54 Rancangan Layar Menu “Menu Makanan” untuk Admin

Gambar 3.54

Rancangan Layar Menu “Menu Makanan” untuk Admin p.106
Gambar 3.55 Rancangan Layar Menu Stok untuk Admin

Gambar 3.55

Rancangan Layar Menu Stok untuk Admin p.107
Gambar 3.56 Rancangan Layar Menu Pegawai untuk Admin

Gambar 3.56

Rancangan Layar Menu Pegawai untuk Admin p.108
Gambar 3.57 Rancangan Layar Menu User untuk Admin

Gambar 3.57

Rancangan Layar Menu User untuk Admin p.109
Gambar 3.59 Rancangan Layar Menu Kategori Makanan untuk Admin

Gambar 3.59

Rancangan Layar Menu Kategori Makanan untuk Admin p.111
Gambar 3.60 Rancangan Layar Menu Laporan untuk Admin

Gambar 3.60

Rancangan Layar Menu Laporan untuk Admin p.112
Gambar 3.61 Rancangan Layar Menu Transaksi untuk Admin

Gambar 3.61

Rancangan Layar Menu Transaksi untuk Admin p.113

Referensi

Memperbarui...

Related subjects :