Datenbankdesign des Zimmerbuchungssystems in einem Hotel


7

Intro und Systembeschreibung


Ich entwerfe derzeit eine Datenbank für ein Zimmerbuchungssystem in einem Hotel.

Der Kunde füllt ein Formular / eine Anfrage mit folgenden Informationen zu Room aus :

  • Anzahl der Personen im Raum
  • Bewertung eines Raumes
  • Ein- und Auscheckdatum

Der Administrator verfügt über ein Dashboard mit einer Liste der Formulare von Clients . Er weist jedem Client jeden Raum manuell zu. Danach erhält der Benutzer eine Rechnung .


Datenbank Design


Dies ist eigentlich eine Skizze meiner Datenbank. Ich werde folgende Tabellen haben :

  • Benutzer
  • Formen
  • Räume
  • Rechnungen

Ich erwäge nicht Tabelle Passwörter , die enthält Passwort des Hashes .

Tischgestaltung


Fragen


Ich würde gerne von Ihnen hören, was in meinem DB-Design fehlt, was Sie über die Gesamtlogik und die Richtigkeit der Beziehungen zwischen Tabellen denken.


3
Diese Frage würde bei der Codeüberprüfung nicht zum Thema gehören, da sie keinen Code enthält (in diesem Zusammenhang DDL). Es ist hier ein Thema und Programmierer (aber bitte fragen Sie nicht nach beiden!)
Paul White 9

1
@rain bitte erwähnen Sie die Definition für Client und Benutzer. Ist der Kunde ein Buchungsagent?
Rathish

Antworten:


15

Ohne genaue und vollständige Anforderungen können wir kein vollständiges Datenmodell entwerfen. Nehmen wir die folgenden Geschäftsregeln an, die auf Ihrer Frage basieren.

  • Jeder Kunde kann ein oder mehrere Zimmer anfordern.
  • Jedes Zimmer kann von einem Kunden angefordert werden
  • Jeder Administrator kann einen oder mehrere Räume zuweisen.
  • Jeder Raum muss von einem Administrator zugewiesen werden.
  • Jeder Raum muss zu einem Raumtyp gehören.
  • Jeder Raumtyp kann einen oder mehrere Räume enthalten.
  • Jede Buchung muss zu einem Datum gehören.
  • Jedes Datum kann eine oder mehrere Buchungen enthalten.
  • Jeder Zimmertyp kann eine oder mehrere Mieten enthalten.
  • Jede Miete muss zu einem Zimmertyp gehören.
  • Jede Buchung muss ein oder mehrere Zimmer enthalten.
  • Jedes Zimmer kann in einer Buchung enthalten sein.
  • Jeder Kunde kann eine oder mehrere Buchungen durchführen.
  • Jede Buchung muss einem Kunden gehören.
  • Jede Miete kann in einer oder mehreren Rechnungen enthalten sein.
  • Jede Rechnung muss eine Miete enthalten.
  • Jede Rechnungszahlung muss eine Zahlungsart enthalten.
  • Jede Zahlungsart kann eine oder mehrere Rechnungszahlungen enthalten.
  • Jedes Datum kann eine oder mehrere Rechnungszahlungen enthalten.
  • Jede Rechnungszahlung muss zu einem Datum gehören.
  • Jeder Raum kann mit einer oder mehreren Raumbewertungen bewertet werden.
  • Jede Zimmerbewertung muss zu einem Raum gehören.
  • Jede Bewertung kann eine oder mehrere Raumbewertungen enthalten.
  • Jede Zimmerbewertung muss zu einer Bewertung gehören.

Basierend auf den obigen Regeln haben wir das folgende Datenmodell entworfen. System zur Buchung von Hotelzimmern

Dieses Modell ist eine Teilmenge des Hotelbuchungssystems . Nach dem Normalisierungsprozess (siehe hier ) erhalten Sie ein detaillierteres und vollständigeres Modell.

In dem obigen Modellraum ist Miete basierte auf dem Zimmer - Typ, wie Einzelzimmer, Doppelzimmer, Familienzimmer oder Meeting Hall statt Anzahl der Personen im Raum berechnet.

Und Zimmermiete wird von Zeit zu Zeit geändert, so dass wir das von Datum und bisher aufgenommen haben Geschichte der Raummieten zu haben. Der Kunde kann auch viele Zahlungsarten wie Kreditkarte, Debitkarte und Barzahlung verwenden, sodass wir als Zahlungsart enthalten sind .

Dieses Modell basiert auf der Annahme. Ich hoffe, dieses Modell wird Ihnen irgendwie helfen.

Vielen Dank.


Es ist eine ziemlich genaue Antwort. IMO-Datumsentität erhöht hier unnötig die Komplexität. Jede Art von Monats- / Jahreskategorisierung oder -darstellung kann sowohl auf SQL-Abfrage- als auch auf Anwendungsebene erfolgen. Ich würde eine datetime-Spalte für alle Entitäten RENT, BILLPAY und BOOKING verwenden, anstatt eine Beziehung zu einer separaten Entität DATE zu haben.
Edigu

1

Nehmen Sie die Rätselraten aus Ihren Abfragen und Ihrem Design heraus, indem Sie beschreibende Namen und Titel verwenden. Roomshat Peopleaber ich würde annehmen das ist eigentlich so etwas wie Capacityoder Room Size. Dies vermeidet Verwechslungen mit der bereits verwendeten PeopleSpalte in Forms. Natürlich könnte dies auch verbessert werden ... so etwas NumberOfGuestswäre jetzt wahrscheinlich informativer für Sie und jeden, der Ihre Datenbank später abfragt. Ich würde alle Spalten- und Tabellennamen überprüfen, um sicherzustellen, dass sie präzise und klar sind.

Räume haben keine automatische Inkrementierung, wahrscheinlich weil Sie erwarten, dass Sie Ganzzahlen verwenden, um Räume zu identifizieren. Dies mag funktionieren, aber Sie können Probleme vermeiden, indem Sie Ihre Geschäfts- / Benutzerraumidentifikation von Ihrer Datenbanklogik trennen. Wenn in Raum 13 ein grausamer Mord begangen wird, der ihn unbrauchbar macht, und der neue Manager, nicht im geringsten abergläubisch oder besorgt über solche Angelegenheiten, diesen Besenschrank auf Etage 14 in Raum 13 verwandelt, weil er groß genug ist und offen gesagt die Qualität unseres Hotels abnimmt .... du bist beschissen. Mit einem von Ihrer Raumbezeichnung getrennten DB-Schlüssel können Sie alle Datensätze und die DB-Integrität sowie die Tatsache beibehalten , dass eine wesentliche Änderung vorgenommen wurde (welche anderen Arten der Änderungsverfolgung und Details sollten wir unterstützen?).Room 13 | RoomPK 13kennt sich als Raum 13 aus, kann aber jetzt tatsächlich Room 13 | RoomPK 132auch aufgenommen werden. Es ist wichtig, wenn jemand versucht, Sie zu verklagen, als er in Zimmer 13 war, und der gesamte Fall hängt davon ab, in welchem Zimmer 13 er übernachtet hat. Entschuldigung, Ihr Hotel hat viele Probleme.

Die letzte Frage ist, wo sind die Transaktionen? Ich würde erwarten, dass ein Formular auch FKs für Bill (s?) Und Rooms (s?) Haben muss. Die Leute müssen irgendwo ein- und auschecken und wir müssen sie speziell für dieses Ereignis und diese Assoziation belasten. Eine Familie kann zwei Zimmer für zwei Tage bekommen, dann morgens auschecken und abends wieder einchecken. Sie sind dann fest davon überzeugt, dass sie nur eine einzige Rechnung erhalten ... Oder jemand, der zwei Nächte bleibt, benötigt zwei Rechnungen aufgrund von zwei verschiedenen Zahlungsmethoden (Kreditkarte, Bargeld, Arbeit, persönlich). Wahrscheinlich benötigen Sie jetzt Nachschlagetabellen, um die Feinheiten der Abrechnung und Buchung zu unterstützen. Die Leute teilen Rechnungen, wechseln die Räume und kehren hoffentlich wieder zurück - all das müssen Sie unterstützen.


-1

Bei der Entwicklung des Hotelmanagementsystems konzentrieren wir uns auf die folgenden Anforderungen:

Das System sollte die Buchung verschiedener Zimmertypen wie Standard, Deluxe, Familiensuite usw. unterstützen.

Gäste sollten in der Lage sein, das Zimmerinventar zu durchsuchen und jedes verfügbare Zimmer zu buchen.

Das System sollte in der Lage sein, Informationen abzurufen, z. B. wer ein bestimmtes Zimmer gebucht hat oder welche Zimmer von einem bestimmten Kunden gebucht wurden.

Das System sollte es Kunden ermöglichen, ihre Buchung zu stornieren und ihnen eine volle Rückerstattung zu gewähren, wenn die Stornierung vor 24 Stunden nach dem Check-in erfolgt.

Das System sollte in der Lage sein, Benachrichtigungen zu senden, wenn sich die Buchung dem Check-In- oder Check-Out-Datum nähert.

Das System sollte ein Raumprotokoll führen, um alle Reinigungsaufgaben zu verfolgen.

Jeder Kunde sollte in der Lage sein, Zimmerservice und Lebensmittel hinzuzufügen. Kunden können nach verschiedenen Annehmlichkeiten fragen. Die Kunden sollten in der Lage sein, ihre Rechnungen mit Kreditkarte, Scheck oder Bargeld zu bezahlen.

Hier ist ein Klassendiagramm für das Hotelbuchungssystem. Hoffe das hilft.

Geben Sie hier die Bildbeschreibung ein


2
Die Frage war nach Datenbankdesign , nein?
Mustaccio
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.