Design eines Hotelzimmer Buchungssystem

Caid

Grünschnabel
Hallo ersteinmal an Alle,
ich bin neue in diesem Forum.

Mein Anliegen:

Für das Abschulss-Projekt eines SAP-DB-Java-Webprogrammierungskurses,
realisiere den Webauftritt einer Hotelkette (fiktiv).
Ich stocke im moment beim Design und Implementierung des Buchungssystem für die zimmern.

Die Anforderungen:
- Jedes Hotel bietet saison und somit Zimmern nach Zeiträume an: von tt.mm.yy bis tt.mm.yy

- Der Kunde kann über Internet frei buchen: von tt.mm.yy bis tt.mm.yy

- Ich muss also bei einer Suchanfrage des kunden, abfragen können ob jenes Hotels beim gewünschten Zeitraum, Zimmer zur Verfügung stellen kann !

Mein Problem:
- Wie realisiere ich, die Abhängigkeit Zimmer-Zeitraum-Buchung möglich, am besten ?

- Damit meine Abfragen nach: "hat dieses Zimmers jenes Hotels in diesem Zeitraum freie Kapazitäten ?", sich intuitiv und unkompliziert realisieren lassen ?

Meine Gedanken:

1- Ich hatte an einem Kalender (Wie kann die Tabelle dafür aussehen ? ), das jedes Zimmer mitführt, wo die Belegung festgehalten werden, gedacht !

N.B. habe ich aber ersteinmal verworfen, weil ich meinte zu Primitiv als Vorgehensweise.

2- Bin aber mit der nächste Lösung die mir einfiel nicht viel weiter gekommen:
Code:
CREATE TABLE Saison (
       S_ID                 int IDENTITY,
       S_Name               varchar(30) NULL,
       Anfang               varchar(10) NOT NULL,
       Ende                 varchar(10) NOT NULL,
       Preis_Faktor         float NOT NULL,
       PRIMARY KEY (S_ID)
)

CREATE TABLE Saison_Belegung (
       S_ID                 int NOT NULL,
       SB_ID                int IDENTITY,
       B_ID                 int NOT NULL,
       Ab                   varchar(10) NULL,
       Tage                 int NULL,
       PRIMARY KEY (SB_ID, S_ID, B_ID), 
       FOREIGN KEY (B_ID)
                             REFERENCES Buchung, 
       FOREIGN KEY (S_ID)
                             REFERENCES Saison
)

CREATE TABLE Buchung (
       B_ID                 int IDENTITY,
       ZK_ID                int NULL,
       H_ID                 int NULL,
       Z_ID                 int NULL,
       Kunden_ID            int NOT NULL,
       P_ID                 int NOT NULL,
       V_ID                 int NOT NULL,
       von                  varchar(10) NOT NULL,
       bis                  varchar(10) NOT NULL,
       beendet              bit,
       PRIMARY KEY (B_ID), 
       FOREIGN KEY (Z_ID, ZK_ID, H_ID)
                             REFERENCES Zimmer, 
       FOREIGN KEY (Kunden_ID, P_ID)
                             REFERENCES Kunde, 
       FOREIGN KEY (V_ID)
                             REFERENCES Verpflegung
)

Will heissen:
- Saison_Belegung ist eine zwischen-Tabelle von Buchung und Saison
- Saison speichert den möglichen Zeitraum
- eine Buchung speichert den gewünschten BelegungsZeitraum zum Zimmer
-> Ergo:
Buchung kann mehrere "Saison_Belegung" instanzieren, wenn über mehreren Zeiträume

Zusammengefasst:
Ich komme da nicht mehr weiter, es scheint mir dass, die Berechnung und Suche nachher bei dem Design, sich sehr schwer realisieren lassen.


Meine Fragen:

- Welchen Ansatz hättet ihr gewählt ?
- Wo kann mein Gedanken-Fehler liegen ?

N.B. Ich bitte mein Deutsch zu entschuldigen, ich bin Ausländer !

Vielen Dank im voraus für jede Anregung.
 
Hallo!

Solch ein System ist schon eine etwas schwierigere Angelegenheit bei der man die Vorgaben genau Spezifizieren muss und ohne all diese zu kennen ist es sehr schwierig bzw. unmöglich ein konsistentes Datenmodell zu entwerfen. Deshalb bekommst du (IMHO) auch keine Antwort.

Du hast z.Bsp in deiner Tabelle Saison_Belegung das Feld Tage.
Weshalb legst du das so einzeln ab und lässt das nicht mit einer Abfrage dynamisch errechnen. Die Datengrundlage dazu müsste ausreichend sein.
...

Ansonsten gibts eben Probleme in der Behandlung von Buchungskonflikten wie etwa Doppelbelegungen / Zeitraumüberschneidungen etc.

Schau doch mal bei Sourceforge ( http://www.sf.net ) unter der Software Map bei Business/Office nach der Kategorie Scheduling ... dort haben sich schon einige Leute die Mühe gemacht solche Probleme zu lösen. Eventuell bringt dich ja ihr Ansatz weiter.

Z.Bsp. dieser hier:

MRBS is a free, GPL, web application using PHP and MySQL/pgsql for booking meeting rooms. It's similar in concept to Netscape Calendar, but much cheaper!

http://mrbs.sourceforge.net/

Das hier ist vielleicht auch noch interessant:

http://sourceforge.net/projects/cr-scheduler/

Gruß Tom
 
Hallo Tom und danke für die Antwort !

Solch ein System ist schon eine etwas schwierigere Angelegenheit bei der man die Vorgaben genau Spezifizieren muss und ohne all diese zu kennen ist es sehr schwierig bzw. unmöglich ein konsistentes Datenmodell zu entwerfen. Deshalb bekommst du (IMHO) auch keine Antwort.

Dachte ich mir schon, setzte aber darauf dass es vielleicht ein paar Leute gibt, die mit dem Thema schon zu tun gehabt hätten.

Du hast z.Bsp in deiner Tabelle Saison_Belegung das Feld Tage.
Weshalb legst du das so einzeln ab und lässt das nicht mit einer Abfrage dynamisch errechnen. Die Datengrundlage dazu müsste ausreichend sein.

Ich wollte das Feld Tage als offset benutzen (den ich würde es im Code aus den Eingaben des Nutzers berechnen, da der Code verantwortlich wäre für die Aufteilung und Zuweisung auf die betreffenden Saisons).
Heiss, ich speichere nur das Anfangsdatum und die Menge Tage die hinzugezählt werden müssen für den jeweiligen Zeitraum innerhalb der Saison.

So würde ich, bei der Suche eines freien Slots(innerhalb einer Saison):
- Überprüfen zwischen welche 2 Positionen (2 unterschiedliche Anfangsdatums), das gewünschte Anfangsdatum liegt.

- ob zwischen Ihnen noch plazt ist

- Wenn ja, ob von nächsten freien Offset nach hinzuaddieren des gewünschten Offsets (Tage), wir schon am zweiten Anfangsdatum angekommen sind.

- Wenn ja : dann speicherung unmöglich
- Wenn nein: speicherung möglich

Ansonsten gibts eben Probleme in der Behandlung von Buchungskonflikten wie etwa Doppelbelegungen / Zeitraumüberschneidungen etc.

Da hast du völlig recht, deshalb das viele Grübbeln meinerseits.


Auf jeden Fall, grossen Dank für die Links und Hinweise.
Ich gehe die mal durchstöbern.
Gute Ideen die funktionieren und schon erprobt sind...

Nochmal danke,
schöne Grüsse aus Hannover.
 
Zurück