映画館予約システムのデータベースモデルを設計する方法

あなたは映画に行くのが好きですか？予約システムの背後にあるデータベース設計がどのように見えるかを考えたことはありますか？この記事では、映画館のデータベースモデルの例を準備します。

留意しなければならないいくつかの仮定があります：

現代のマルチプレックス映画館は、より大きな複合施設内に1つ以上の講堂を持つことができます。
各講堂の座席数は異なる場合があります
座席は、列番号と列内の座席位置で番号が付けられます。
映画は、異なる時間に複数の上映される場合もあれば、異なる講堂で同時に上映される場合もあります。
上映ごとに、座席の予約/販売は1回のみ可能です。
各予約/販売をシステムに入力した人を追跡したい。

この問題を解決するための1つの可能なデータベース設計を見てみましょう（モデルはVertabelo for MySQLデータベースで作成されました）：

短いテーブル構造の説明を以下に示します：

movie 表には、劇場で上映される映画に関するデータが含まれています。主キーはidです、これは他のすべてのテーブルのすべての主キーと同様にauto_incrementedです。唯一の必須データはtitleです。

すべてのフィールドには、その名前に応じた意味があります。列duration_min 新しいスクリーニングの挿入を無効にしたり、前のスクリーニングがまだ進行中の講堂でスクリーニングを開始したい場合にアラートメッセージを表示したりするために使用できます：
previous screening start time + duration_min of it > this screening start time
auditorium 表は、劇場内のすべての講堂を示しています。すべてのデータは必須です。

seats_no フィールドを使用して、選択した上映/映画/講堂/日付範囲の講堂の可用性のパーセンテージを計算できます。これはデータの冗長性の例です seat テーブル。この例では、パフォーマンスが大幅に向上しない可能性があります。ここでは、より複雑なモデルの設計に役立つ可能性のあるアイデアとして示します。このようにデータベースを設定する場合、1つのデータを変更すると、他のデータも変更する必要があることに注意する必要があります。 seatからデータを追加または削除した場合テーブル値を調整する必要がありますseats_no auditorium テーブル。
screening 表にはすべてのスクリーニングのデータが含まれており、すべてのフィールドは必須です。上映には、関連する映画、講堂、開始時間が必要です。同じ講堂で同時に2つの上映を行うことはできません。 auditorium_idで構成される一意のキーを定義できますおよびscreening_start 。この設定は、movie_idで構成される一意のキーを定義するよりも優れています、auditorium_id 、およびscreening_start これにより、同じ講堂で2つの異なる映画の上映に同時に参加できるようになるからです。

このテーブルのVertabeloSQLプレビューコードは次のようになります（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 表には、講堂にあるすべての座席のリストが含まれており、各座席は厳密に1つの講堂に割り当てられています。すべてのフィールドは必須です。
reservation_type 表は、すべての予約タイプの辞書です（電話、オンライン、直接）。すべてのフィールドは必須です。
employee 表には、システムを使用しているすべての従業員がリストされています。すべてのフィールドは必須です。

複雑なシステムでは通常、より多くの役割があるため、役割ディクショナリと従業員/ユーザーと役割の接続が必要です。この例では、役割は1つだけです。同じ人が予約を挿入し、チケットを販売します。
reservation およびseat_reserved テーブルは、システムのメインテーブルです。これが私が最後にそれらをリストした理由です。他のすべてのテーブルは予約テーブルなしで存在できますが、予約テーブルがないと、そもそもデータベース全体を設計する理由が失われます。

reservation テーブルには、チケットの予約および/または販売に関するデータが格納されます。予約がある場合、属性reserved reservation_type_idであるTrueに設定されます予約の発信元とemployee_reserved_idに応じて設定されます id_employeeが含まれますデータを入力した人の値（顧客がオンラインで予約した場合は空になります）。同様に、チケットが販売された場合、employee_paid_id id_employeeで埋められますチケットを販売した人の値、支払われた属性はTrueに設定されます。 active属性は、レコードがまだ有効かどうかを識別します。チケットが販売された場合、この属性は常にTrueになり、販売なしの予約は、スクリーニングが開始される30分前までアクティブになります

seat_reserved テーブルを使用すると、複数の座席の予約または1回の支払いを行うことができます。従業員がインターフェイスのいくつかの空席を確認した後、それぞれについて1つのレコードがこのテーブルに追加されます。空席または空席を確認したい場合は、reservation reservation.active = Trueのテーブル。

言及する価値があります：

employee_reserved_id 座席の予約が存在しない可能性があるため（座席のチケットは事前の予約なしで販売されます）、またはオンラインで行われるため、必須ではありません
reservation_type_id 予約タイプの「id」を参照する外部キーです。予約が存在しない可能性があるため、必須ではありません（事前の予約なしで販売した場合）
reservation_contact 予約した人のデータを保存するためのテキスト入力フィールドです。予約が存在しない可能性があるため、必須ではありません（事前の予約なしで販売した場合）
employee_paid_id 販売を行ったユーザーに関連している場合、販売が行われなかった可能性があるため必須ではありません（座席が予約された、予約が自動的にキャンセルされた、座席が販売されていない）
paid 支払いが行われたことを示すフラグであり、必須です（値はYes/TrueまたはNo/Falseの場合があります）

結局、自分の席に誰か他の人を見つけるのが好きな人はいないことを覚えておいてください：