酒店預訂數據庫設計問題
我目前正在設計(作為大學課程的作業)一個用於線上預訂全球酒店的數據庫,我偶然發現了一個問題。
這是概念設計:
以下是迄今為止的關係佈局表:
GUEST
guest_ID varchar PK
email varchar
guest_password varchar
first_name varchar
last_name varchar
mobile_num varchar
member_status varchar
pref_language varchar
pref_currency_code varchar
HOTEL
hotel_ID varchar PK
hotel_name varchar
ratings_avg int
phone_num varchar
email varchar
currency_code varchar
street_name varchar
street_num varchar
zip_code varchar
city varchar
country varchar
ROOM
room_ID varchar PK
hotel_ID varchar FK to Hotel
room_name varchar
low_season_rate numeric
high_season_rate numeric
max_persons int
BOOKING guest_ID
varchar FK to Guest
room_ID varchar FK to Room
check_in date
check_out date
(前 4 個組合為 PK)
persons_num int
PAYMENT
guest_ID varchar FK to Guest
room_ID varchar FK to Room
date_paid timestamp
amount numeric
EVALUATION
guest_ID varchar FK 到 Guest
hotel_ID varchar FK 到 Hotel
eval_date 日期
(前 3 個作為 PK 的組合)
rating int
guest_comment text
我想出這個設計構想是這樣的:客人會預訂屬於酒店的房間,支付房間費用,然後,如果他們願意,在入住後對酒店進行評估。
所以我認為預訂和付款是客人和房間之間的關係,而評價是客人和酒店之間的關係。
這種設計似乎存在的問題是付款和評估與預訂完全斷開,因此即使沒有預先存在的預訂,他們的桌子也可以填滿。
我現在看到的方式是,客人支付房間住宿(=預訂)並評估酒店住宿(=預訂),所以我認為這些表應該參考預訂表。
但是 Booking 是一個關係,我可以在一個實體和另一個關係之間形成一個關係嗎?或者它可以被視為一個實體?
我歡迎任何關於這個主題的想法。
我認為 PAYMENT 指的是 BOOKING 沒有任何問題。從 BOOKING 開始,為什麼 check_out 是 PK 的一部分?我不明白你怎麼可以多次退房,以便辦理入住手續。鑑於:
CREATE TABLE BOOKING ( guest_ID varchar NOT NULL -- FK to Guest , room_ID varchar NOT NULL -- FK to Room , check_in date NOT NULL , PRIMARY KEY (guest_ID, room_ID, check_in) , ... );
對於 PAYMENT,您需要確定它與什麼 BOOKING 相關,因此包含 check_in 是有意義的:
CREATE TABLE PAYMENT ( guest_ID varchar NOT NULL , room_ID varchar NOT NULL , check_in date NOT NULL , FOREIGN KEY (guest_ID, room_ID, check_in) REFERENCES BOOKING (...) , date_paid timestamp NOT NULL -- , amount numeric NOT NULL );
PAYMENT我特意省略了PK,如果需要全額支付,前3列就足夠了,如果可以部分支付,可以包括date_paid。
其他考慮,預訂的約定價格是多少?房間的價格可能會因季節、活動等而有所不同。如果我們假設價格以某種方式屬於預訂,則僅在部分付款的情況下才需要支付的金額,否則,要麼支付或不支付賬單
對於評估,是否有理由包括酒店而不是房間?您可以從房間中推斷出酒店,這也可以將評估與預訂聯繫起來,就像付款一樣。