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

Transkripsi

1 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 Sejarah Perusahaan Raja Kepiting merupakan sebuah perusahaan yang bergerak dibidang restoran. Menu utama yang disajikan di restoran Raja Kepiting adalah makanan seafood. Restoran Raja Kepiting yang pertama didirikan pada tanggal 17 Agustus 2006, berlokasi di Jalan Raya Serpong KM 7 No. 35 Serpong (Depan WTC Matahari). Tujuan didirikannya Restoran Raja Kepiting ini adalah untuk memenuhi para penikmat makanan seafood pada khususnya. Telah menjadi komitmen, Restoran Raja Kepiting hanya akan menyediakan hidangan kepiting dengan kualitas terbaik saja. Kepiting yang disajikan pun berasal dari berbagai wilayah Indonesia, seperti Tarakan dan Timika. Kepiting merupakan menu unggulan yang disajikan oleh restoran ini. Saus kepiting yang terbaik dan digemari adalah lada hitam (black pepper) dan saus padang (chili sauce), namun masih tersedia saus lain yang tidak kalah lezatnya, seperti saus tiram (oyster sauce), asam manis 67

2 (sweet and sour sauce), goreng mentega (fried butter sauce), dan telor asin (salted egg). 68 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 Struktur Organisasi Dalam suatu organisasi, terdapat hubungan diantara sumber daya manusia dengan segala aktivitas bisnis yang ada. Semakin banyak kegiatan yang dilakukan dalam suatu organisasi, semakin kompleks hubungan-hubungan yang ada. Untuk itu perlu dibuat suatu bagan yang menggambarkan hubungan-hubungan tersebut yaitu dengan struktur organisasi. Struktur organisasi perusahaan harus memungkinkan adanya koordinasi kerja antara semua satuan dan jenjang untuk tindakantindakan dalam mencapai tujuan umum perusahaan.

3 69 Struktur organisasi memerinci pembagian aktivitas kerja dan selain itu struktur organisasi juga menunjukkan hirarki dari organisasi, pembagian tugas, tanggung jawab dan wewenang. Kepiting. Berikut ini merupakan struktur organisasi dari Restoran Raja Gambar 3.1 Struktur Organisasi

4 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 71 - Membuat makanan dan minuman dari pesanan tamu restoran - Mengkoordinasikan penyajian makanan dan minuman dengan Food & Beverage Service Finance & Accounting, memiliki wewenang dan tanggung jawab antara lain: - Bertugas mengatur keuangan restoran - Bertanggung jawab atas laporan keuangan restoran - Memoitor serta mengontrol pelayanan dari Cashier Cashier, memiliki wewenang dan tanggung jawab antara lain : - Bertanggung jawab atas transaksi pembayaran Food & Beverage Service, memiliki wewenang dan tanggung jawab antara lain : - 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 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 Diagram Konteks Gambar 3.2 Diagram Konteks Sistem yang Sedang Berjalan

7 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 Prosedur Pemesanan Makanan Berikut ini adalah prosedur untuk memesan makanan pada Restoran Raja Kepiting : 1. Pelanggan yang datang akan langsung diantar ke meja yang tersedia.

8 74 2. Kemudian pelayan akan memberikan daftar menu makanan kepada pelanggan. 3. Pelanggan memilih menu makanan dan kemudian pelayan akan mencatatnya pada kertas yang telah disediakan. 4. Setelah itu pelayan akan menyerahkan kertas pesanan tersebut ke bagian dapur. Gambar 3.4 Proses Bisnis Pemesanan Makanan Prosedur Penambahan Pesanan Makanan Jika pelanggan akan menambah pesanan, maka berikut ini adalah prosedur yang dilakukan : 1. Pelanggan akan memanggil pelayan.

9 75 2. Pelayan akan mencatat pesanan tambahan yang diinginkan oleh pelanggan. 3. Kemudian pesanan tersebut akan diserahkan ke bagian dapur. Gambar 3.5 Proses Bisnis Penambahan Pesanan Makanan Prosedur Pembayaran Tagihan Jika pelanggan telah selesai makan, maka prosedur untuk melakukan pembayaran adalah sebagai berikut : 1. Pelanggan datang ke kasir. 2. Kemudian kasir akan memberikan total tagihan kepada pelanggan, 3. Lalu pelanggan memberikan uang ke kasir. 4. Kasir akan mencatat tagihan dan jumlah pembayaran ke mesin kasir.

10 5. Selanjutnya kasir memberikan struk tagihan, dan jika ada uang kembali, maka akan diserahkan kepada pelanggan. 76 Gambar 3.6 Proses Bisnis Pembayaran Tagihan 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 77 5. Bahan makanan yang sudah dikirimkan oleh pemasok akan disimpan terlebih dahulu di gudang penyimpanan sebelum akhirnya didistribusikan ke cabang-cabang Restoran Raja Kepiting. Gambar 3.7 Proses Bisnis Pembelian Stok Bahan Makanan 3.4 Analisis Permasalahan yang Dihadapi Setelah dilakukan analisis pada sistem yang sedang berjalan, dan berdasarkan data data yang didapat dari hasil observasi dan wawancara, maka didapatkan beberapa kendala atau masalah yang dihadapi Restoran Raja Kepiting.

12 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 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 79 2. Pelanggan yang akan memesan sendiri menu makanannya, sehingga meminimalkan kesalahan yang terjadi saat proses pemesanan. 3. Sistem akan menyimpan riwayat pesanan dan total tagihan ke dalam database, sehingga akan memudahkan pihak restoran untuk melihat data laporan pemasukan. 4. Sistem stok yang akan dibuat akan menyimpan dan menampilkan jumlah stok yang masuk 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 : Diagram Konteks Gambar 3.8 Diagram Konteks Sistem yang Diusulkan

14 Diagram Nol Gambar 3.9 Diagram Nol Sistem yang Diusulkan

15 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) 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 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 82 Tabel 3.1 Identifikasi Tipe Entitas No Entitas Deskripsi Alias Occurrence Pegawai Orang-orang Employee Setiap pegawai 1 yang berkerja di perusahaan bekerja pada satu bidang tertentu Meja Perlengkapan Table Setiap yang digunakan pelanggan 2 sebagai tempat memiliki satu makan pelanggan untuk meja makan Pesanan Menggambarkan Order Setiap pesanan 3 pesanan produk yang dilakukan pelanggan yang dilakukan oleh pelanggan MenuMakanan Menggambarkan Produk Setiap menu hasil dari bahan makanan yang 4 baku yang telah di proses menjadi makanan dihasilkan dari proses produksi StokBahanMakanan Menggambarkan Raw Setiap bahan 5 bahan makanan material makanan yang yang digunakan ada di stok

17 83 untuk membuat produk Pembayaran Menggambarkan Payment Setiap proses pembayaran 6 pembayaran pesanan dilakukan jika pelanggan telah selesai makan Review Mengambarkan Review Review proses feedback dilakukan jika 7 pelanggan terhadap makanan yang dimakan pelanggan telah selesai makan 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 84 a. Perancangan ERD (Entity Relationship Diagram) Menghitung_Stok 0..* StokBahanMakanan 1..* 1..* Memengaruhi_Menu 1..1 Pegawai 1..1 Memengaruhi_Stok 1..* MenuMakanan 1..* 1..* Review 0..1 Menerima_Pembayaran Melakukan_Pemesanan Pesanan 1..* * Menghasilkan_Pembayaran 1..1 Melengkapi_Pesanan Memberikan_Saran_Komentar 0..* Pembayaran * 1..1 Meja 1..1 Melakukan_Pembayaran Gambar 3.10 Entity Relationship Diagram tahap Konseptual

19 85 b. Penentuan multiplicity dari hasil relasi Tabel 3.2 Identifikasi Tipe Relasi Entitas Multiplicity Relationship Multiplicity Entitas Pegawai 1..1 Menghitung_ 0..* StokBahanMakanan Stok 1..1 Menerima_Pe 0..* Pembayaran mbayaran Meja 1..1 Memberikan_ 0..1 Review Saran_Komen tar 1..1 Melakukan_P 1..* Pesanan emesanan 1..1 Melakaukan_ 0..* Pembayaran Pembayaran Pesanan 1..1 Menghasilkan 1..1 Pembayaran _Pembayaran MenuMakanan 1..* Melengkapi_P 1..* Pesanan esanan StokBahanMakanan 1..* Memengaruhi 1..* Menu Makanan _Menu 1..* Memengaruhi 1..* Pesanan _Stok

20 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 Multivalued Pegawai IdPegawai Atribut unik untuk Char (5) Tidak Tidak identifikasi pegawai NamaPegawai Nama pegawai Varchar(30) Tidak Tidak Jabatan Jabatan pegawai Varchar (20) Tidak Tidak JenisKelamin TanggalLahir Jenis kelamin pegawai Tanggal lahir pegawai Char (1) Tidak Tidak Date Tidak Tidak Alamat Alamat pegawai Varchar (200) Tidak Tidak NomorHP Nomor HP Pegawai Varchar (16) Ya Tidak Meja IdMeja Atribut unik untuk Char (3) Tidak Tidak identifikasi

21 87 NamaMeja Username Password Status pelanggan Nomor meja pelanggan Username untuk login aplikasi Password untuk login aplikasi Status dari meja tersebut Varchar(10) Tidak Tidak Varchar (10) Tidak Tidak Varchar (5) Tidak Tidak Int Tidak Tidak Pesanan IdPesanan Atribut unik untuk Char (5) Tidak Tidak identifikasi pesanan makanan NamaMenu Nama menu Varchar(100) Tidak Tidak JumlahPesanan Harga TotalHarga TanggalPesan StatusPesanan Jumlah pesanan pelanggan Harga satuan menu makanan Total harga keseluruhan pesanan pelanggan Waktu pesanan makanan Status pesanan makanan Int Tidak Tidak Float Tidak Tidak Float Tidak Tidak Date Tidak Tidak Int Tidak Tidak MenuMakana IdMenu Atribut unik untuk Char (5) Tidak Tidak

22 88 n identifikasi menu makanan NamaMenu Nama menu Varchar (30) Tidak Tidak makanan Harga Harga satuan Float Tidak Tidak menu makanan Deskripsi Deskripsi dari Varchar (100) Ya Tidak menu makanan StokBahanMa IdStok Atribut unik untuk Char (5) Tidak Tidak kanan identifikasi stok bahan makanan 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 TanggalMasuk Jumlah stok yang ada Tanggal masuk bahan makanan Int Tidak Tidak Date Tidak Tidak Pembayaran IdPembayaran Atribut unik untuk Char (5) Tidak Tidak TotalHarga identifikasi pembayaran Total harga pesanan menu Float Tidak Tidak

23 89 JumlahPembayaran JumlahUangKembali TanggalPembayaran makanan Jumlah pembayaran yang diberikan pelanggan Jumlah uang kembalian pelanggan Tanggal pembayaran Float Tidak Tidak Float Tidak Tidak Date Tidak Tidak Review IdReview Atribut unik untuk Char (5) Tidak Tidak Review Tanggal identifikasi review Isi review pelanggan Tanggal pengisian review Varchar (50) Tidak Tidak Date Tidak Tidak 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 90 Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama. Tabel 3.4 Determinasi Domain Atribut Entitas Atribut Domain Atribut Pegawai IdPegawai 5 karakter dengan format Exxxx, dimana karakter E merupakan kode pegawai dan empat karakter berikutnya merupakan nomor pegawai NamaPegawai Jabatan JenisKelamin Variasi karakter dengan maksimal jumlah 50 karakter Variasi karakter dengan maksimal jumlah 20 karakter Sebuah karakter M untuk jenis kelamin laki-laki atau F untuk jenis kelamin perempuan TanggalLahir Alamat NomorHP Tanggal dengan format dd-mm-yyyy Variasi karakter dengan maksimal jumlah 100 karakter 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 Username Password Status Variasi karakter dengan maksimal jumlah 10 karakter Variasi karakter dengan maksimal jumlah 15 karakter Variasi karakter dengan maksimal jumlah 5 karakter Angka bulat (non-desimal) Pesanan IdPesanan 5 karakter dengan format Oxxxx, dimana karakter O

25 merupakan kode pesanan dan empat karakter berikutnya merupakan nomor pesanan 91 NamaMenu Variasi karakter dengan maksimal jumlah 10 karakter JumlahPesanan Angka bulat (non-desimal) Harga TotalHarga TanggalPesan StatusPesanan Angka bulat (non-desimal) Angka bulat (non-desimal) Tanggal dengan format dd-mm-yyyy 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 StokBahanMaka nan NamaMenu Harga Deskripsi IdStok NamaBahan SatuanUkuran HargaSatuanU kuran MinimumStok JumlahStok Variasi karakter dengan maksimal jumlah 30 karakter Angka bulat (non-desimal) Variasi karakter dengan maksimal jumlah 100 karakter 5 karakter dengan format Sxxxx, dimana karakter S merupakan kode stok dan empat karakter berikutnya merupakan nomor stok Variasi karakter dengan maksimal jumlah 15 karakter Variasi karakter dengan maksimal jumlah 6 karakter Angka bulat (non-desimal) Angka bulat (non-desimal) Angka bulat (non-desimal)

26 92 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 JumlahPembay Angka bulat (non-desimal) Angka bulat (non-desimal) aran JumlahUangKe Angka bulat (non-desimal) mbali TanggalPemba Tanggal dengan format dd-mm-yyyy yaran Review IdReview 5 karakter dengan format Fxxxx, dimana karakter F merupakan kode untuk review / feedback dan empat karakter berikutnya merupakan nomor review Review Tanggal Variasi karakter dengan maksimal jumlah 50 karakter Tanggal dengan format dd-mm-yyyy 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. 93 Tabel 3.5 Identifikasi Candidate Key dan Primary Key Entity Candidate Key Primary Key Pegawai Meja Pesanan MenuMakanan Idpegawai Namapegawai Alamat Nomorhp IdMeja NamaMeja Username Idpesanan Namamenu Idmenu Namamenu Idpegawai IdMeja Idpesanan Idmenu StokBahanMakanan Idstok Idstok Namabahan Pembayaran Idpembayaran Idpembayaran Review Idreview Idreview

28 94 Gambar 3.11 Entity Relationship Diagram tahap Konseptual dengan Primary Key

29 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 96 b. Hubungan One to One antara Pesanan dan Pembayaran Gambar 3.13 Hubungan Antara Pesanan dan Pembayaran Entitas Pesanan dan Pembayaran tidak redundan dan keduanya tidak dapat digabungkan menjadi satu entitas, karena objek masing masing entitas berbeda. 2. Memeriksa Redundansi a. Hubungan antara Stok Bahan Makanan, Menu Makanan dan Pesanan Relasi Awal : Gambar 3.14 Hubungan Awal Antara Stok Bahan Makanan, Menu Makanan dan Pesanan

31 97 Relasi memengaruhi stok antara Pesanan dan Stok Bahan Makanan redundan, karena data Pesanan memengaruhi Stok Bahan Makanan dapat dilihat juga dari relasi memengaruhi antara Stok Bahan Makanan dan Menu Makanan. Sehingga tidak diperlukan relasi tambahan antara Pesanan dan Stok Bahan Makanan, karena Stok Bahan Makanan akan dipengaruhi dari jumlah yang digunakan dalam Menu Makanan. Relasi akhir : Gambar 3.15 Hubungan Akhir Antara Stok Bahan Makanan, Menu Makanan dan Pesanan

32 98 b. Hubungan antara Pembayaran, Meja dan Pesanan Relasi awal : Gambar 3.16 Hubungan Awal Antara Pembayaran, Meja, dan Pesanan Relasi melakukan pembayaran antara Meja dan Pembayaran redundan, karena data Meja melakukan pembayaran dapat dilihat juga dari relasi menghasilkan pembayaran antara Pesanan dan Pembayaran. Sehingga tidak diperlukan relasi tambahan antara Meja dan Pembayaran, karena data Meja dapat dilihat dari relasi

33 menghasilkan pembayaran antara Pesanan dan Pembayaran. 99 Relasi akhir : Gambar 3.17 Hubungan Akhir antara Pembayaran, Meja, dan Pesanan

34 100 Gambar 3.18 Entity Relationship Diagram Konseptual Setelah Penghilangan Hubungan Redundansi 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 101 pengguna aplikasi. Dibawah ini akan dijelaskan mengenai tinjauan dari beberapa user yang ada, antara lain : 1. Pegawai memasukan stok dan atau melakukan pengecekan terhadap ketersediaan barang (bahan makanan) yang ada. 2. Pelanggan masuk ke dalam sistem aplikasi melalui akun yang telah diberikan, setelah itu pelanggan melakukan pemesanan menu makanan. 3. Pelanggan memberikan saran / komentar (review) atas menu makanan yang telah di konsumsi. 4. Pelanggan melakukan pembayaran atas tagihan yang di dapat dari pesanan. 5. Pegawai menerima pembayaran yang dilakukan pelanggan.

36 102 Gambar 3.19 Validasi Model Konseptual dengan Transaksi Pengguna 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 103 berdasarkan model konseptual yang telah dibuat pada tahap perancangan basis data sebelumnya 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 ) Primary Key ( IdPelanggan )

38 104 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. Tidak terdapat entitas lemah dalam model data ini.

39 105 c. Identifikasi Tipe Binary Relationship 1:* Pada entitas entitas yang mempunyai hubungan one-to-many memiliki ciri yang unik yaitu entitas yang berada di sisi one menjadi parent, dan entitas yang berada di sisi many menjadi child. 1. Tambahkan IdPegawai menjadi foreign key pada Pesanan untuk hubungan 1..* melayani_pesanan antara Pegawai dan Pesanan. Gambar 3.20 Relasi one to many Antara Pegawai dan Pesanan 2. Tambahkan IdPegawai menjadi foreign key pada StokBahanMakanan untuk hubungan 1..* menghitung_stok antara Pegawai dan StokBahanMakanan.

40 106 Gambar 3.21 Relasi one to many Antara Pegawai dan StokBahanMakanan 3. Tambahkan IdPegawai menjadi foreign key pada Pembayaran untuk hubungan 1..* menerima_pembayaran antara Pegawai dan Pembayaran. Gambar 3.22 Relasi one to many Antara Pegawai dan Pembayaran 4. Tambahkan IdPegawai menjadi foreign key pada Review untuk hubungan 1..* menerima_saran_komentar antara Pegawai dan Review.

41 107 Gambar 3.23 Relasi one to many Antara Pegawai dan Review 5. Tambahkan IdMeja menjadi foreign key pada Pesanan untuk hubungan 1..* melakukan_pemesanan antara Meja dan Pesanan. Gambar 3.24 Relasi one to many Antara Meja dan Pesanan

42 108 d. Tipe Binary Relationship 1:1 Entitas entitas yang berhubungan secara one-to-one dibuat menjadi satu relasi yang sama menggunakan mandatory participation pada kedua sisinya. Entitas yang terlibat kemudian digabungkan dan dipilih satu primary key dari entitas asal, jika ada primary key lain maka akan menjadi alternate key. 1. Tambahkan IdMeja menjadi foreign key pada Review untuk relasi 1..1 yang menggunakan mandatory participation memberikan_saran_komentar antara Meja dan Review. Gambar 3.25 Relasi one to one Antara Meja dan Review

43 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 Relasi awal :

44 110 Gambar 3.27 Relasi Awal many to many antara StokBahanMakanan dan MenuMakanan Karena relasi antara StokBahanMakanan dan MenuMakanan bersifat many-to-many, maka tidak bisa secara langsung menggabungkan kedua tabel tersebut. Diperlukan suatu tabel baru untuk dapat menggabungkan kedua tabel tersebut. Relasi akhir : Gambar 3.28 Relasi Akhir many to many Antara StokBahanMakanan dan MenuMakanan

45 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 112 Relasi akhir : Gambar 3.30 Relasi Akhir many to many Antara MenuMakanan dan Pesanan f. Atribut Multi-Value Atribut multi-value adalah atribut yang memiliki lebih dari 1 nilai. Jika terdapat atribut multi-value maka harus dibuatkan satu entitas baru untuk mewakili atribut multi-value, kemudian primary key entitas tersebut dimasukkan pada relasi yang baru berperan sebagai foreign key. Pada model data ini tidak terdapat atribut multi-value Memvalidasi Relasi Menggunakan Normalisasi Tahap selanjutnya yaitu, melakukan normalisasi terhadap relasi yang dibuat sebelumnya. Tahap validasi relasi menggunakan normalisasi yang bertujuan untuk menghilangkan

47 113 anomali anomali data yang ada. Dalam tahap ini terdapat beberapa entitas yang sudah dalam bentuk normal, sehingga tidak diperlukan validasi normalisasi lagi terhadap entitas tersebut. Berikut ini adalah hasil normalisasi yang ada, yaitu : Validasi 1NF : Sebuah relasi dimana persimpangan setiap baris dan kolom berisi satu dan hanya satu nilai (Connolly & Begg, 2005, p403). Sebuah relasi akan berada dalam bentuk 1NF jika repeating group sudah hilang. Pesanan UNF : Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga, TotalHarga, TanggalPesan, StatusPesanan, IdMeja, Username, IdPegawai, NamaPegawai, IdMenu ) Hasil 1NF : Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga, TanggalPesan, StatusPesanan, IdMeja, Username, IdPegawai, NamaPegawai, IdMenu ) Menu Makanan UNF : MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi, IdStok, NamaBahan )

48 114 Hasil 1NF : MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi, IdStok, NamaBahan ) Validasi 2NF : Menurut Connolly dan Begg (2005, p407) relasi dikatakan 2NF jika relasi berada pada 1NF dan setiap atribut yang bukan primary key bergantung sepenuhnya (full functionally dependent) terhadap primary key. Full functionally dependent terjadi jika A dan B merupakan atribut dari suatu relasi, dan B dikatakan bergantung penuh terhadap A (A->B), namun bukan subset dari A. Pesanan 1NF : Pesanan ( IdPesanan, NamaMenu, JumlahPesanan, Harga, TanggalPesan, StatusPesanan, IdMeja, Username, IdPegawai, NamaPegawai, IdMenu ) Hasil 2NF : Pesanan ( IdPesanan, TanggalPesan, StatusPesanan, IdMeja, Username, IdPegawai, NamaPegawai )

49 PesananDetail ( IdPesanan, IdMenu, NamaMenu, Harga, JumlahPesanan ) 115 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 ) 116 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 Gambar 3.31 Entity Relationship Diagram Logikal 117

52 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 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 119 Pembayaran ( IdPembayaran, TanggalPembayaran, Idpesanan, IdPegawai ) Primary Key IdPembayaran Foreign Key IdPesanan References Pesanan ( IdPesanan ) ON DELETE CASCADE ON UPDATE CASCADE Foreign Key IdPegawai References Pegawai ( IdPegawai ) ON DELETE CASCADE ON UPDATE CASCADE Pesanan ( IdPesanan, TanggalPesan, StatusPesanan, IdPegawai, IdMeja ) Primary Key IdPesanan Foreign Key IdPegawai References Pegawai ( IdPegawai ) ON DELETE CASCADE ON UPDATE CASCADE Foreign Key IdMeja References Meja ( IdMeja ) ON DELETE CASCADE ON UPDATE CASCADE PesananDetail ( IdMenu, IdPesanan, Qty, HargaSatuan, Total) Primary Key IdMenu, IdPesanan Foreign Key IdMenu References MenuMakanan ( IdMenu ) ON DELETE CASCADE ON UPDATE CASCADE Foreign Key IdPesanan References Pesanan ( IdPesanan ) ON DELETE CASCADE ON UPDATE CASCADE

54 120 MenuMakanan ( IdMenu, NamaMenu, Harga, Deskripsi, IdKategoriMakanan ) Primary Key IdMenu MenuMakananDetail ( IdMenu, IdStok, Qty ) Primary Key IdMenu, IdStok Foreign Key IdMenu References MenuMakanan ( IdMenu ) ON DELETE CASCADE ON UPDATE CASCADE Foreign Key IdStok References StokBahanMakanan ( IdStok) ON DELETE CASCADE ON UPDATE CASCADE StokBahanMakanan ( IdStok, NamaBahan, SatuanUkuran, Harga, MinimumStok, JumlahStok, TanggalMasuk, IdPegawai ) Primary Key IdStok Foreign Key IdPegawai References Pegawai ( IdPegawai ) ON DELETE CASCADE ON UPDATE CASCADE Review ( IdReview, Review, TanggalReview, IdMeja, IdPegawai ) Primary Key IdReview Foreign Key IdMeja References Meja ( IdMeja ) ON DELETE CASCADE ON UPDATE CASCADE Foreign Key IdPegawai References Pegawai ( IdPegawai ) ON DELETE CASCADE ON UPDATE CASCADE

55 121 KategoriMakanan ( IdKategoriMakanan, KategoriMakanan ) Primary Key IdKategoriMakanan User ( Username, Password, HakAkses, IdPegawai ) Primary Key Username 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 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 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 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 TanggalLahir : Tipe Data karakter, length 1 harus M atau F : 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 123 JenisKelamin char(1) NOT NULL, TanggalLahir date NOT NULL, Alamat varchar(200) NOT NULL, NomorHP varchar(16) NOT NULL, PRIMARY KEY (`IdPegawai`) ) ; 2. Meja Keterangan: IdMeja : Tipe Data variasi karakter, length 3 NamaMeja : Tipe Data variasi karakter, length 10 UserName : Tipe Data variasi karakter, length 10 Password : Tipe Data variasi karakter, length 5 Status : Tipe Data integer, length 1 CREATE TABLE Meja ( IdMeja char(3) NOT NULL, NamaMeja varchar(10) NOT NULL, Username varchar(10) NOT NULL, Password varchar(5) NOT NULL, Status int(1) NOT NULL, PRIMARY KEY (`IdMeja`)

58 124 ); 3. Pembayaran Keterangan: IdPembayaran : Tipe Data karakter, length 5 TanggalPembayaran : Tipe Data datetime JumlahPembayaran : Tipe Data integer, length 7 Idpesanan : Tipe Data karakter, length 5 IdPegawai : Tipe Data karakter, length 5 CREATE TABLE Pembayaran ( Idpembayaran char(5) NOT NULL, TanggalPembayaran date NOT NULL, JumlahPembayaran int(7) NOT NULL, IdPesanan char(5) NOT NULL, IdPegawai char(5) NOT NULL, PRIMARY KEY (`Idpembayaran`), FOREIGN KEY (`IdPesanan`) REFERENCES Pesanan (`IdPesanan`) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (`IdPegawai`) REFERENCES Pegawai (`IdPegawai`) ON DELETE CASCADE ON UPDATE CASCADE );

59 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 126 HargaSatuan : Tipe Data integer, length 6 Bumbu : Tipe Data variasi karakter, length 50 Catatan : Tipe Data variasi karakter, length 255 Status : Tipe Data integer, length 1 CREATE TABLE PesananDetail ( IdMenu char(5) NOT NULL, IdPesanan char(5) NOT NULL, Qty int(2) unsigned NOT NULL, HargaSatuan int(6) unsigned NOT NULL, Bumbu varchar(50) NOT NULL, Catatan varchar(255) NOT NULL, Status int(1) NOT NULL, PRIMARY KEY (`IdMenu`,`IdPesanan`), FOREIGN KEY (`IdMenu`) REFERENCES `MenuMakanan` (`IdMenu`) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (`IdPesanan`) REFERENCES `Pesanan` (`IdPesanan`) ON DELETE CASCADE ON UPDATE CASCADE );

61 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 128 CREATE TABLE MenuMakanan ( IdMenu char(5) NOT NULL, NamaMenu varchar(100) NOT NULL, Harga int(6) unsigned NOT NULL, Deskripsi varchar(100) NOT NULL, NamaGambar varchar(50) NOT NULL, IdKategoriMakanan char(3) NOT NULL, PRIMARY KEY (`IdMenu`), FOREIGN KEY (`IdKategoriMakanan`) REFERENCES `KategoriMakanan` (`IdKategoriMakanan`) ON DELETE CASCADE ON UPDATE CASCADE ); 8. MenuDetail Keterangan: IdMenu : Tipe Data karakter, length 5 IdStok : Tipe Data karakter, length 5 Qty : Tipe Data variasi karakter, length 25 CREATE TABLE MenuDetail ( IdMenu char(5) NOT NULL, IdStok char(5) NOT NULL, Qty varchar(25) NOT NULL,

63 129 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 ( IdStok char(5) NOT NULL,

64 130 NamaBahan varchar(25) NOT NULL, SatuanUkuranTotal varchar(6) NOT NULL, Harga int(6) unsigned NOT NULL, MinimumStok int(3) unsigned NOT NULL, SatuanUkurMin varchar(10) NOT NULL, JumlahStok int(3) unsigned NOT NULL, TanggalMasuk date NOT NULL, IdPegawai char(5) NOT NULL, Catatan varchar(255) NOT NULL, PRIMARY KEY (`IdStok`), FOREIGN KEY (`IdPegawai`) REFERENCES `Pegawai` (`IdPegawai`) ON DELETE CASCADE ON UPDATE CASCADE ); 10. Review Keterangan: IdReview : Tipe Data karakter, length 5 Review : Tipe Data variasi karakter, length 255 TanggalReview : Tipe Data datetime, IdMeja : Tipe Data karakter, length 3 CREATE TABLE Review ( IdReview char(5) NOT NULL, Review varchar(255) NOT NULL,

65 131 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 132 ); 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 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 133 CHECK ( JenisKelamin IN ( P, W )) 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 Menganalisis Transaksi Analisis transaksi ini bertujuan untuk memahami fungsionalitas dari transaksi yang dapat terjadi dari basis data fisikal. Transaksi transaksi yang dapat terjadi adalah sebagai berikut : a. Menambah, mengubah dan menghapus data pegawai b. Melihat data pegawai c. Menambah, mengubah dan menghapus data meja d. Melihat data meja e. Menambah, mengubah data pembayaran f. Melihat data pembayaran g. Menambah, mengubah dan menghapus data pesanan h. Melihat data pesanan

68 134 i. Menambah, mengubah dan menghapus data review j. Melihat data review k. Menambah, mengubah dan menghapus stok bahan makanan l. Melihat data stok bahan makanan m. Menambah, mengubah dan menghapus data menu makanan detail n. Melihat data menu makanan detail o. Menambah, mengubah dan menghapus data menu makanan p. Melihat data menu makanan q. Menambah, mengubah dan menghapus data pesanan detail r. Melihat data pesanan detail s. Menambah, mengubah dan menghapus data kategori makanan t. Melihat data kategori makanan u. Menambah, mengubah dan menghapus data user v. Melihat data user

69 135 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 Tabel 3.8 Analisis Transaksi Pembayaran dan Pesanan

70 136 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 PesananDetail X 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 137 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 Tabel 3.11 Analisis Transaksi PesananDetail dan KategoriMakanan

72 138 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 139 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 140 U merupakan kepanjangan dari Update, yang berarti user dapat mengubah data. D merupakan kepanjangan dari Delete, yang berarti user dapat menghapus data. R merupakan kepanjangan dari Read, yang berarti user hanya dapat membuka dan tidak dapat memodifikasi data 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) 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 141 Berikut adalah rancangan indeks yang digunakan pada entitas entitas yang terdapat pada basis data. Tabel 3.13 Perancangan Indeks Tabel Indeks Pegawai Meja Pembayaran idpegawai idmeja idpembayaran idpegawai idpesanan Pesanan idpesanan idmeja Review idreview idmeja StokBahanMakanan Idstok idpegawai MenuMakananDetail idmenu idstok MenuMakanan idmenu

76 142 idkategorimakanan PesananDetail idmenu idpesanan KategoriMakanan User idkategorimakanan username idpegawai 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 143 Tabel 3.14 Estimasi Tabel Pegawai Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) Pegawai IdPegawai Karakter 5 NamaPegawai Jabatan Variasi Karakter Variasi Karakter JenisKelamin Karakter 1 TanggalLahir Date 8 Alamat NomorHP Total Variasi Karakter Variasi Karakter byte

78 144 Kapasitas dari table pegawai adalah 280 byte Data yang ada saat ini 13 pegawai, total penggunaan tabel pegawai = 13 * 280 = 3640 byte Diperkirakan dalam 1 tahun terjadi penambahan pegawai sebanyak 10 Dalam waktu 5 tahun pertumbuhan dari table pegawai adalah 10 * 5 * 280 = byte Sehingga total pertumbuhan tabel pegawai selama 5 tahun ditambah data awal = = byte Tabel 3.15 Estimasi Tabel Meja Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) Meja IdMeja Karakter 3 NamaMeja Username Password Variasi Karakter Variasi Karakter Variasi Karakter Status Integer 4

79 145 Total 32 byte Kapasitas dari table meja adalah 32 byte Data yang ada saat ini 25 meja, total penggunaan tabel meja = 25 * 32 = 800 byte Diperkirakan dalam 1 tahun terjadi penambahan meja sebanyak 10 Dalam waktu 5 tahun pertumbuhan dari table meja adalah 10 * 5 * 32 = 1600 byte Sehingga total pertumbuhan tabel meja selama 5 tahun ditambah data awal = = 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 146 Diperkirakan dalam 1 bulan terjadi penambahan transaksi (pembayaran) sebanyak 600 Dalam waktu 1 tahun pertumbuhan dari tabel pembayaran adalah 600 * 12 * 27 = byte Dalam waktu 5 tahun pertumbuhan dari table pembayaran adalah 5 * = byte Sehingga total pertumbuhan tabel pembayaran selama 5 tahun ditambah data awal = = 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 Dalam waktu 1 tahun pertumbuhan dari table pesanan

81 147 adalah 600 * 12 * 20 = byte Dalam waktu 5 tahun pertumbuhan dari table pesanan adalah 5 * = byte Sehingga total pertumbuhan tabel pesanan selama 5 tahun ditambah data awal = = 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 catatan Variasi Karakter Variasi Karakter Status Integer 4 Total 327 byte Kapasitas dari table pesanandetail adalah 327 byte

82 148 Data yang ada saat ini 25 pesanan detail, total penggunaan tabel pesanandetail = 10 * 25 = 250 byte Diperkirakan dalam 1 bulan terjadi transaksi pemesanan sebanyak 600 Dalam waktu 1 tahun pertumbuhan dari table pesanan adalah 600 * 12 * 327 = byte Dalam waktu 5 tahun pertumbuhan dari table pesanan adalah 5 * = byte Sehingga total pertumbuhan tabel pesanandetail selama 5 tahun ditambah data awal = = 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 NamaGambar Variasi Karakter Variasi Karakter

83 149 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 = byte Dalam waktu 1 tahun penambahan menumakanan sebanyak 10 Dalam waktu 5 tahun pertumbuhan dari table menumakanan adalah 5 * 10 * 262 = byte Sehingga total pertumbuhan tabel menumakanan selama 5 tahun ditambah data awal = = byte Tabel 3.20 Estimasi Tabel MenuMakananDetail Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) MenuDetail IdMenu Karakter 5 IdStok Karakter 5 Qty Total Variasi Karakter byte Kapasitas dari table menudetail adalah 35 byte (tiap 1 menu) Data yang ada saat ini 150 menu makanan detail, total

84 150 penggunaan tabel menumakanandetail = 150 * 35 = 5250 byte Dalam waktu 1 tahun penambahan menudetail sebanyak 20 Dalam waktu 5 tahun pertumbuhan dari table menudetail adalah 5 * 20 * 35 = 3500 byte Sehingga total pertumbuhan tabel menumakanandetail selama 5 tahun ditambah data awal = = 8750 byte Tabel 3.21 Estimasi Tabel StokBahanMakanan Nama Entitas Nama Atribut Tipe Data Ukura n (Bytes) StokBahanMakana IdStok Karakte 5 n r NamaBahan Variasi 25 Karakte r SatuanUkuranTota Variasi 6 l Karakte r Harga Integer 4 MinimumStok Integer 4

85 151 SatuanUkurMin Variasi Karakte r 10 JumlahStok Integer 4 TanggalMasuk Date 8 IdPegawai catatan Karakte r Variasi Karakte r Total 326 byte Kapasitas dari table stokbahanmakanan adalah 326 byte Data yang ada saat ini 120 stok bahan makanan, total penggunaan tabel stokbahanmakanan = 120 * 326 = 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 = byte Sehingga total pertumbuhan tabel stokbahanmakanan selama

86 152 5 tahun ditambah data awal = = 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 153 Dalam waktu 1 tahun pertumbuhan dari table review adalah 450 * 12 * 271 = byte Dalam waktu 5 tahun pertumbuhan dari table review adalah 5 * = byte Sehingga total pertumbuhan tabel review selama 5 tahun ditambah data awal = = byte Tabel 3.23 Estimasi Tabel KategoriMakanan Nama Entitas Nama Atribut Tipe Data Ukuran (Bytes) KategoriMakanan IdKategoriMakanan Karakter 3 KategoriMakanan Total Variasi Karakter 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 154 Dalam waktu 5 tahun pertumbuhan dari table kategorimakanan adalah 5 * 530 = 2650 byte Sehingga total pertumbuhan tabel review selama 5 tahun ditambah data awal = = 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 Dalam waktu 1 tahun pertumbuhan dari table user adalah 10

89 155 * 51 = 510 byte Dalam waktu 5 tahun pertumbuhan dari table user adalah 5 * 510 = 2550 byte Sehingga total pertumbuhan tabel user selama 5 tahun ditambah data awal = = 2754 byte 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 Perancangan Aplikasi Tahap dimana aplikasi dirancang dan terdiri dari 3 tahap yaitu perancangan struktur menu, STD, dan rancangan layar input/output Perancangan Struktur Menu Berikut ini adalah struktur menu dari aplikasi yang akan dirancang :

91 157 Gambar 3.32 Struktur Menu Admin Gambar 3.33 Struktur Menu User