Cách thiết kế mô hình cơ sở dữ liệu cho hệ thống đặt chỗ rạp chiếu phim

Bạn có thích đi xem phim không? Bạn đã bao giờ xem thiết kế cơ sở dữ liệu đằng sau hệ thống đặt chỗ của họ trông như thế nào chưa? Trong bài viết này, chúng tôi sẽ chuẩn bị một mô hình cơ sở dữ liệu mẫu cho một rạp chiếu phim.

Có một số giả định mà chúng tôi phải ghi nhớ:

các rạp chiếu phim ghép nối hiện đại có thể có một hoặc nhiều khán phòng trong một khu phức hợp lớn hơn,
mỗi khán phòng có thể có số lượng chỗ ngồi khác nhau,
ghế được đánh số bằng số hàng và vị trí ghế trong một hàng,
một bộ phim có thể có nhiều buổi chiếu vào các thời điểm khác nhau hoặc có thể được chiếu đồng thời trong một khán phòng khác nhau,
đối với mỗi buổi chiếu, một chỗ chỉ có thể được đặt trước / bán một lần,
chúng tôi muốn theo dõi những ai đã nhập từng đặt chỗ / bán hàng vào hệ thống.

Hãy xem xét một thiết kế cơ sở dữ liệu có thể có để giải quyết vấn đề này (mô hình được tạo bằng Vertabelo cho cơ sở dữ liệu MySQL):

Dưới đây là mô tả cấu trúc bảng ngắn gọn:

movie bảng chứa dữ liệu về các bộ phim sẽ được chiếu tại rạp. Khóa chính là id , được auto_incremented giống như tất cả các khóa chính trong tất cả các bảng khác. Dữ liệu bắt buộc duy nhất là title .

Tất cả các trường đều có ý nghĩa theo tên của chúng. Cột duration_min có thể được sử dụng để vô hiệu hóa việc chèn một buổi chiếu mới hoặc để hiển thị một thông báo cảnh báo trong trường hợp chúng tôi muốn tham gia một buổi chiếu trong một khán phòng nơi buổi chiếu trước đó vẫn đang diễn ra:
previous screening start time + duration_min of it > this screening start time
auditorium bảng xác định tất cả các khán phòng trong nhà hát. Tất cả dữ liệu là bắt buộc.

seats_no trường có thể được sử dụng để tính toán tỷ lệ phần trăm khả dụng của khán phòng cho một buổi chiếu / phim / khán phòng / phạm vi ngày đã chọn. Đây là một ví dụ về dự phòng dữ liệu bởi vì chúng tôi có thể nhận được số lượng chỗ ngồi cho mỗi khán phòng bằng cách đếm chúng trong seat bàn. Trong ví dụ này, nó có thể không cải thiện đáng kể hiệu suất. Tôi trình bày nó ở đây như một ý tưởng có thể giúp thiết kế các mô hình phức tạp hơn. Nếu chúng ta thiết lập cơ sở dữ liệu theo cách này, chúng ta phải nhớ rằng nếu chúng ta thay đổi một phần dữ liệu, chúng ta cũng phải thay đổi những phần khác. Nếu chúng tôi thêm hoặc xóa dữ liệu khỏi seat bảng chúng ta phải điều chỉnh các giá trị seats_no trong auditorium bàn.
screening bảng chứa dữ liệu của tất cả các sàng lọc và tất cả các trường là bắt buộc. Một buổi chiếu phải có một bộ phim liên quan, khán phòng và thời gian bắt đầu. Chúng ta không thể có hai buổi chiếu trong cùng một khán phòng cùng một lúc. Chúng tôi có thể xác định một khóa duy nhất bao gồm auditorium_id và screening_start . Thiết lập này tốt hơn là xác định một khóa duy nhất bao gồm movie_id , auditorium_id và screening_start bởi vì điều đó sẽ cho phép chúng tôi tham gia các buổi chiếu hai bộ phim khác nhau cùng một lúc trong cùng một khán phòng.

Mã xem trước Vertabelo SQL cho bảng này trông như thế này (lưu ý 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 bảng chứa danh sách tất cả các chỗ ngồi mà chúng ta có trong khán phòng với mỗi chỗ ngồi được chỉ định cho một khán phòng. Tất cả các trường là bắt buộc.
reservation_type bảng là một từ điển của tất cả các loại đặt phòng (qua điện thoại, trực tuyến, trực tiếp). Tất cả các trường là bắt buộc.
employee bảng liệt kê tất cả nhân viên sử dụng hệ thống. Tất cả các trường là bắt buộc.

Trong các hệ thống phức tạp thường có nhiều vai trò hơn nên chúng ta cần có một từ điển vai trò và kết nối vai trò nhân viên / người dùng. Trong ví dụ của chúng tôi, chúng tôi chỉ có một vai trò:cùng một người đặt chỗ và bán vé.
reservation và seat_reserved bảng là bảng chính của hệ thống của chúng tôi. Đây là lý do tại sao tôi liệt kê chúng cuối cùng. Tất cả các bảng khác có thể tồn tại mà không có bảng đặt chỗ nhưng nếu không có bảng đặt chỗ, chúng ta sẽ mất lý do thiết kế toàn bộ cơ sở dữ liệu ngay từ đầu.

reservation bảng lưu trữ dữ liệu về đặt chỗ và / hoặc bán vé. Nếu chúng tôi đặt chỗ trước, thuộc tính reserved sẽ được đặt thành True, reservation_type_id sẽ được đặt theo nguồn gốc của đặt chỗ và employee_reserved_id sẽ chứa id_employee giá trị của người đã nhập dữ liệu (sẽ trống nếu khách hàng đã thực hiện đặt chỗ trực tuyến). Theo cách tương tự, nếu vé đã được bán, employee_paid_id sẽ được điền bằng id_employee giá trị của người đã bán vé, thuộc tính trả tiền sẽ được đặt thành True. Thuộc tính hoạt động xác định nếu một bản ghi vẫn còn hợp lệ. Nếu vé đã được bán, thuộc tính này sẽ luôn là True và việc đặt trước không có bán sẽ có hiệu lực cho đến 30 phút trước khi buổi chiếu bắt đầu

seat_reserved bàn cho phép chúng tôi đặt chỗ hoặc một lần thanh toán cho nhiều chỗ ngồi. Sau khi nhân viên kiểm tra một vài chỗ ngồi miễn phí trên giao diện, một bản ghi sẽ được thêm vào bảng này cho mỗi người trong số họ. Nếu chúng tôi muốn kiểm tra chỗ ngồi nào còn trống hoặc đã lấy, chúng tôi có thể kiểm tra các giá trị trong bảng này được kết hợp với reservation bảng trong đó reservation.active = True .

Điều đáng nói:

employee_reserved_id không bắt buộc vì đặt chỗ có thể không tồn tại (vé cho chỗ được bán mà không cần đặt trước) hoặc được thực hiện trực tuyến
reservation_type_id là một khóa ngoại tham chiếu đến “id” của loại đặt chỗ. Điều này không bắt buộc vì có thể không đặt trước (trong trường hợp chúng tôi bán hàng mà không đặt trước)
reservation_contact là trường nhập văn bản để lưu trữ dữ liệu của một người đã đặt trước, không bắt buộc vì đặt trước có thể không tồn tại (trong trường hợp chúng tôi bán hàng mà không đặt trước)
employee_paid_id có liên quan đến người dùng đã thực hiện giao dịch bán hàng, không bắt buộc vì giao dịch bán có thể đã không diễn ra (chỗ đã được đặt trước, đặt chỗ tự động bị hủy, chỗ chưa được bán)
paid là một lá cờ cho biết rằng việc thanh toán đã xảy ra và là bắt buộc (giá trị có thể là Có / Đúng hoặc Không / Sai)

Cuối cùng, hãy nhớ rằng không ai thích tìm người khác ngồi vào chỗ của mình: