Bagaimana Merancang Model Database untuk Sistem Reservasi Bioskop

Apakah Anda suka pergi ke bioskop? Pernahkah Anda mempertimbangkan seperti apa desain database di balik sistem reservasi mereka? Dalam artikel ini kita akan menyiapkan contoh model database untuk bioskop.

Ada beberapa asumsi yang harus kita ingat:

Bioskop multipleks kontemporer dapat memiliki satu atau lebih auditorium dalam kompleks yang lebih besar,
setiap auditorium dapat memiliki jumlah kursi yang berbeda,
kursi diberi nomor dengan nomor baris dan posisi kursi dalam satu baris,
sebuah film dapat diputar beberapa kali pada waktu yang berbeda, atau dapat diputar secara bersamaan di auditorium yang berbeda,
untuk setiap pemutaran, kursi hanya dapat dipesan/dijual satu kali,
kami ingin melacak siapa yang memasukkan setiap reservasi/penjualan ke dalam sistem.

Mari kita lihat satu desain database yang mungkin untuk memecahkan masalah ini (model dibuat dengan Vertabelo untuk database MySQL):

Deskripsi struktur tabel singkat diberikan di bawah ini:

movie tabel berisi data tentang film yang akan diputar di bioskop. Kunci utamanya adalah id , yang auto_incremented seperti semua kunci utama di semua tabel lainnya. Satu-satunya data wajib adalah title .

Semua bidang memiliki arti sesuai dengan namanya. Kolom duration_min dapat digunakan untuk menonaktifkan penyisipan pemutaran baru atau untuk menampilkan pesan peringatan jika kita ingin memasuki pemutaran di auditorium tempat pemutaran sebelumnya masih berlangsung:
previous screening start time + duration_min of it > this screening start time
auditorium tabel mengidentifikasi semua auditorium di teater. Semua data adalah wajib.

seats_no field dapat digunakan untuk menghitung persentase ketersediaan auditorium untuk pemutaran/film/auditorium/rentang tanggal yang dipilih. Ini adalah contoh redundansi data karena kita bisa mendapatkan jumlah kursi untuk setiap auditorium dengan menghitungnya di seat meja. Dalam contoh ini mungkin tidak meningkatkan kinerja secara signifikan. Saya tunjukkan di sini sebagai ide yang dapat membantu merancang model yang lebih kompleks. Jika kita mengatur database dengan cara ini, kita harus ingat bahwa jika kita mengubah satu bagian data, kita juga harus mengubah yang lain. Jika kita menambah atau menghapus data dari seat tabel kita harus menyesuaikan nilai seats_no di auditorium meja.
screening tabel berisi data semua pemutaran dan semua bidang wajib diisi. Pemutaran film harus memiliki film terkait, auditorium, dan waktu mulai. Kami tidak dapat memiliki dua pertunjukan di auditorium yang sama pada waktu yang bersamaan. Kita dapat mendefinisikan kunci unik yang terdiri dari auditorium_id dan screening_start . Penyiapan ini lebih baik daripada mendefinisikan kunci unik yang terdiri dari movie_id , auditorium_id , dan screening_start karena itu akan memungkinkan kita untuk memasuki pemutaran dua film yang berbeda pada waktu yang sama di auditorium yang sama.

Kode pratinjau SQL Vertabelo untuk tabel ini terlihat seperti ini (perhatikan Screening_ak_1):
```
-- Tables
-- Table screening
CREATE TABLE screening (
   id int    NOT NULL  AUTO_INCREMENT,
   movie_id int    NOT NULL ,
   auditorium_id int    NOT NULL ,
   screening_start timestamp    NOT NULL ,
   UNIQUE INDEX Screening_ak_1 (movie_id,auditorium_id,screening_start),
   CONSTRAINT Screening_pk PRIMARY KEY (id)
);
```
seat tabel berisi daftar semua kursi yang kami miliki di auditorium dengan setiap kursi ditugaskan ke satu auditorium. Semua kolom wajib diisi.
reservation_type tabel adalah kamus dari semua jenis reservasi (melalui telepon, online, secara langsung). Semua kolom wajib diisi.
employee tabel daftar semua karyawan yang menggunakan sistem. Semua kolom wajib diisi.

Dalam sistem yang kompleks biasanya ada lebih banyak peran sehingga kita perlu memiliki kamus peran dan koneksi peran karyawan/pengguna. Dalam contoh kami, kami hanya memiliki satu peran:orang yang sama memasukkan reservasi dan menjual tiket.
reservation dan seat_reserved tabel adalah tabel utama dari sistem kami. Inilah mengapa saya mendaftarkannya terakhir. Semua tabel lain bisa ada tanpa tabel reservasi tapi tanpa tabel reservasi kita akan kehilangan alasan untuk mendesain seluruh database sejak awal.

reservation tabel menyimpan data tentang reservasi dan/atau penjualan tiket. Jika kami memiliki reservasi, atribut reserved akan disetel ke True, reservation_type_id akan disetel sesuai dengan asal reservasi dan employee_reserved_id akan berisi id_employee nilai orang yang memasukkan data (akan kosong jika reservasi telah dilakukan secara online oleh pelanggan). Dengan cara yang sama, jika tiket terjual, employee_paid_id akan diisi dengan id_employee nilai orang yang menjual tiket, atribut yang dibayarkan akan disetel ke True. Atribut aktif mengidentifikasi apakah catatan masih valid. Jika tiket terjual, atribut ini akan selalu True dan reservasi tanpa penjualan akan aktif hingga 30 menit sebelum pemutaran dimulai

seat_reserved meja memungkinkan kita untuk membuat reservasi atau satu pembayaran untuk beberapa kursi. Setelah karyawan memeriksa beberapa kursi kosong di antarmuka, satu catatan akan ditambahkan ke tabel ini untuk masing-masing kursi. Jika kita ingin memeriksa kursi mana yang gratis atau diambil, kita dapat memeriksa nilai di tabel ini yang digabungkan ke reservation tabel di mana reservation.active = True .

Perlu disebutkan:

employee_reserved_id tidak wajib karena reservasi mungkin tidak ada untuk kursi (tiket untuk kursi dijual tanpa reservasi sebelumnya) atau dilakukan secara online
reservation_type_id adalah kunci asing yang merujuk pada "id" tipe reservasi. Ini tidak wajib karena reservasi mungkin tidak ada (jika kami melakukan penjualan tanpa reservasi sebelumnya)
reservation_contact adalah kolom input teks untuk menyimpan data orang yang melakukan reservasi, ini tidak wajib karena reservasi mungkin tidak ada (jika kami melakukan penjualan tanpa reservasi sebelumnya)
employee_paid_id terkait dengan pengguna yang melakukan penjualan, tidak wajib karena penjualan mungkin tidak terjadi (kursi sudah dipesan, reservasi dibatalkan secara otomatis, kursi belum terjual)
paid adalah bendera yang menunjukkan bahwa pembayaran telah terjadi dan bersifat wajib (nilainya bisa Ya/Benar atau Tidak/Salah)

Pada akhirnya, ingatlah bahwa tidak ada yang suka menemukan orang lain di kursinya: