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
(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.
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.
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:
- 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).
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
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 :
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 :
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.
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.
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.
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.
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
3.5.2 Diagram Nol
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.
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
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 :
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
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
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
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
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
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.
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)
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)
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
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
Gambar 3.11 Entity Relationship Diagram tahap Konseptual dengan
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.
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
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
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
menghasilkan pembayaran antara Pesanan dan Pembayaran.
• Relasi akhir :
Gambar 3.17 Hubungan Akhir antara Pembayaran, Meja, dan Pesanan
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
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.
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
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 )
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.
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.
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.
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.
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.
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
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
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.
• 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
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 )
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 )
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 )
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 )
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
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
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
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.
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,
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`)
); 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
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
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
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
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,
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 (
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,
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
);
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 :
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
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
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
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
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
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
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.
• ‘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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
* 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.
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
Gambar 3.32 Struktur Menu Admin
3.7.2 State Transition Diagran (STD)
Berikut ini adalah State Transition Diagram (STD) dari aplikasi yang akan dirancang :
Gambar 3.35 STD Menu Utama Admin
Gambar 3.37 STD Admin Menu Stok
Gambar 3.39 STD Admin Menu User
Gambar 3.41 STD Admin Menu Kategori Makanan
Gambar 3.44 STD Menu Utama User
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.
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.
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.
