Cần giúp về chỉnh sửa database

Mình mới học sql và có thiết kế 1 db quản lý khách sạn, yêu cầu nghiệp vụ quan trọng là khách có thể thuê nhiều phòng trong 1 lần thuê mà nhân viên chỉ cần nhập 1 phiếu thuê. Mình có mô hình thực thể như thế này


và 2 quan hệ n-n sẽ sinh ra 2 bảng là: chitietphieuthue và sudungdichvu

nhìn có vẻ khá là ổn khi việc 1 phiếu thuê có nhiều chi tiết phiếu thuê đã giải quyết được vấn đề 1 khách có thể thuê nhiều phòng trong 1 lần thuê. Nhưng khi làm phần mềm thì mới để ý nếu để như vậy thì nó sẽ không phân biệt được phòng nào sử dụng dịch vụ nào khi khách thuê 2 phòng, vì phòng nằm trong chi tiết phiếu thuê, bây giờ nếu cho sudungdichvu kết nối với chitietphieuthue thì sẽ ổn, nhưng về phần lý thuyết chuyển erd => lược đồ quan hệ sẽ bị sai, ai giúp mình được với không ạ, cảm ơn mn ạ!!!

Web càng ngày càng k có người hay sao ấy :((

Hôm nay là chủ nhật, cậu kỳ vọng trang web sẽ đông vui như mall hay rạp chiếu phim à Đạt ơi? :slight_smile:

Về vấn đề của cậu, cậu có thể thấy trong ER diagram cậu vẽ, phiếu thuê phòng có dịch vụ, và có phòng, nhưng dịch vụ không thuộc về phòng. Đó là sai lầm khi cậu design ER, dẫn tới hậu quả bây giờ.
Cậu nên đổi lại là Phòng có dịch vụ, Phiếu thuê phòng có Phòng, và không cần quan hệ giữa Phiếu thuê phòng với dịch vụ nữa, nó đã được cover trong phòng rồi. Từ Er diagram đó, tớ nghĩ cậu có thể chuyển đổi về database design đúng ko? :slight_smile:

Câu hỏi đặt ra ở đây, cậu sẽ làm gì với code của cậu khi cậu sửa DB schema?
Nếu code của cậu đủ tốt, cậu sẽ chỉ cần sửa 1 vài class.
Nếu code của cậu tệ, chúc mừng cậu, cậu đã có bài học đầu tiên: luôn luôn tách biệt object từ DB với object sử dụng với object tính toán/hiển thị.

4 Likes

Vâng, mình cảm ơn bạn, đấy cũng là ý của mình, vì mình là newbie nên có gì sai sót mong bạn bỏ qua cho mình nhé!

Hi Đạt,
Tớ có thể bỏ qua cho cậu 1 lần thôi, cậu có thể giúp tớ sửa đổi lỗi lầm của cậu chứ? :smiley:


Đùa vậy thôi, tớ biết việc cải thiện khó mà. Tớ từng gặp người tự claim là chục năm kinh nghiệm, nhưng vẫn mắc sai lầm của beginner. Tớ không kỳ vọng gì đâu :smiley:

Anw, cậu cần bọn tớ giúp gì được nữa nhỉ Đạt? Vì tớ có nói cậu cần sửa ER diagram, rồi sửa tiếp database design, rồi sửa vào code rồi.
Cậu đang kỳ vọng 1 cách làm workaround giúp cậu không phải sửa nhiều trong code phải không? :wink:

3 Likes

thật ra tớ đang chuẩn bị thi, tất cả phần mềm đều ok hết rồi, giờ viết báo cáo nên cần chỉn chu từ mô hình er cho đến lược đồ quan hệ. Mà tớ post có bài 10 ngày k được 1 ai reply cậu ạ, tớ buồn chán thật sự, nên bây giờ mới comment như thế, xin lỗi cậu và mọi người nhé! Còn recommend của cậu ở trên đúng ý tớ định sửa luôn, phần mềm tớ viết trên winform và dùng ef và có dùng store proc nên giờ mình chỉ cần sửa 1 vài proc liên quan đến bảng đấy thôi cậu ạ, cảm ơn cậu nhé

2 Likes

Tớ hiểu rồi. Đúng là dạo này ít comment trả lời trên diễn đàn hơn thật :smiley: Có lẽ mọi người bận cậu ạ.
Cơ mà, chúc cậu may mắn khi submit bài tập nhé! :smiley: Tớ rất quý người có trách nhiệm trong công việc và biết xin lỗi như cậu. Hi vọng chúng ta có cơ hội gặp nhau trong tương lai gần :smiley:

3 Likes

Cảm ơn cậu đã hiểu cho tớ nhé, hy vọng có thể gặp cậu :smiley:

Cậu ơi giờ tớ làm vậy thì vẫn không ổn ấy, vì bây giờ khách này vào thuê phòng rồi lại sử dụng dịch vụ nhưng khi ra rồi khách khác lại thuê phòng đấy và sử dụng dịch vụ thì nó không phân biệt được mã sử dụng dịch vụ của phòng đấy là của phiếu thuê nào ấy

Lược đồ quan hệ này thì làm rất ổn, đáp ứng được đủ yêu cầu, nhưng từ mô hình er không thể thiết kế ra được như thế này

Hi @Dang_Dat1,

Tớ nghĩ DB schema cuối cùng cậu đưa ra khả thi để implement.
Đừng lo khi mà nó trông khác ER diagram cậu à, thường sau khi cậu chuyển đổi từ ER sang thiết kế DB schema, cậu vẫn cần tinh chỉnh nó chút để phù hợp với việc implement (chuẩn hóa/phi chuẩn hóa/đổi quan hệ…).
Cậu có thể sử dụng point đó khi bảo vệ chương trình của cậu.
Tuy nhiên, nếu cậu thiết kế DB schema như vậy, tớ nghĩ ER của cậu nên đổi lại chút. Mối quan hệ giữa Phiếu thuê, Dịch vụ và Phòng ở đây là mối quan hệ 3 chiều. Như vậy, bảng trung tâm của cậu sẽ trở nên hợp lý.
Cậu có thể đọc thêm ở đây để hiểu thêm.

4 Likes

ý của cậu là mối quan hệ 3 ngôi ntn à?

Tớ muốn hỏi liệu có thể cho chitietphieuthue là 1 thực thể không cậu nhỉ?

Looks good!

Tớ nghĩ là đa số thông tin trong chi tiết phiếu thuê nên ở trong phiếu thuê.
Chi tiết phiếu thuê tớ nghĩ nên là bảng nối, chỉ cần thông tin về mã phòng, mã phiếu thuê và mã sử dụng dịch vụ. Vì vậy, nó không phải là 1 thực thể đâu cậu :smiley:

4 Likes

ừ cậu, nhưng thật sự để 3 ngôi như thế này ra 3 quan hệ n-n cơ, trong khi đó chỉ sinh ra 2 bảng nữa, nghe có vẻ không ổn :((

Nó vẫn là quan hệ n-m mà cậu? Với n là 1 :wink:
Đùa vậy thôi cậu. Ở trong link tớ đưa trong comment này, cậu có thể thấy Ternary Relationship có thể có 1-n-n, hoặc thậm chí là 1-1-1.
Tớ nghĩ cậu nên đọc kỹ article tớ đưa cho. Như vậy, cậu sẽ có đủ lý do để bảo vệ quan điểm dùng Ternary Relationship ở trên.

4 Likes

3 posts were merged into an existing topic: Topic lưu trữ các post off-topic - version 3

3 ngôi thì 1 bảng lấy khóa ngoại 3 bảng thôi bạn :smiley:

[Một bảng nữa là do trong 1 lần thuê phòng có thể dùng 0+ dịch vụ, mỗi dịch vụ có thể dùng 0+ lần]

3 Likes

vậy 1 bảng sinh ra đó là chitietphieuthue, nhưng db cuối của mình bảng đó chỉ là liên kết giữa phong và phieuthue thôi

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?