Im trying to build a hotel application system and now i have laid out plans for the DB. My requirements are a guest searches for availability for a room. A room could either be king or queen, and smoking or non smoking. Also the guest enters the check in and out date. Based on the search the guest enters their info and reserve a room. Based on the reservation the service agent receives the receipt(reservationId). The service agent books the room upon receiving the reservationId. A guest can reserve several rooms per reservation. Now below is how my DB looks right now.
My question is since a guest can have several rooms per reservation how could i represent multiple rooms per reservation. Note: This will be done using hibernate. And below is my actual setup now for my DB please feel free to correct me if my approach is wrong: Below is a draft of how my db looks:
Reservation(resId(PK), checkIndate, checkOutDate, roomType, roomProperties, guestId(FK)).
Guest(guestId(PK), fname, lname, email, license, address_details).
Room(roomId(PK), roomNumber, roomProperties, roomType, price).
Booking(bookId(PK), resId(Fk), roomId)
RoomOccupied(bookId(PK and FK), roomId(PK and FK), flagChecKIfOccupied(default value is 0 if not occupied or 1 if occupied)
Payment(paymentId(PK), resId(FK), finalPayment)
Related
As per these instructions, i am trying to create a ER model. With
these instructions:
Total Escapes has a wide variety of tours on offer to its customers.
Each tour can be uniquely identified by a route ID. A tour also has
associated with it an estimated duration and a description of the tour
itself.
Customer details are to be recorded in the database, with a unique
customer ID generated for each customer. Additional details include a
name, date of birth and contact phone number. A Tour run is defined as
one instance of a tour, i.e. a tour has a number of tour runs. For
example, a ‘Melbourne City Tour’ runs twice every day, 8:30am and
2:30pm. In other words, a Tour run is identified by not only a
specific tour but the date and time that tour was operated.
A customer can book tour runs. The price paid for the booking is
recorded. A vehicle is used by a driver to perform his/her duties in
taking tourists on a route. Each vehicle can be identified by it
registration plates. Other attributes such as vehicle type, capacity
and colour are also recorded.
A Tour guide organizes a tour run in coordination with the driver. The
tour guide must have a unique certificate number to be recorded in the
system. Their name, mobile number and address are also required. The
driver responsible for operating the tour vehicle on a tour run can be
identified by their D/L number. A name and mobile phone number are
also recorded in the database for each driver.
Some tour guides train other tour guides to manage tours themselves.
Each trainee has one supervisor while a supervisor can guide many
trainees.
On the diagram that i have created I am wondering if the link between instance and tour would be the many to exactly one?
OR is the tour run not even a weak entity?
ER Model
I agree that Tour Run is a weak entity - the instructions are very specific about this. That means Instance is an identifying relationship, mapping Route_ID values to Route_ID,Date,Time values. This is a trivial relation that wouldn't need to be recorded separately from Tour Run keys. You're also correct that the association between Instance and Tour is many-to-one - many Route_ID,Date,Time triplets map to one Route_ID.
It is known about each employee of the shipping company what their
first and last names are, their age, residence address, place of
birth, correspondence address, e-mail.
Each employee who is a driver has one of the cars at the disposal. It
is known about the car what make it is, what engine it has, when it
was manufactured, etc.
Each car has a vehicle card, which contains information on failures,
services, repairs, etc.
Shipping company has its customers and gathers the following
information about them: first and last names, address, telephone no.
Customers commission the company the shipping of commodities. About
commodities the following information is known: quantity, weight,
address and date of shipping.
Customer can commission the shipping of more than one commodity. It is
also known what the price of such a service is.
Please, review this ER Diagram that I have designed.
I have used "Look Across" Min-Max notation.
I would slightly change the diagram to display the shipping order as an entity (currently in your diagram it's displayed as a relation), with the following :
Each customer can have many shipping orders.
Each shipping order can contain many commodities.
Hope this helps
For an ecommerce site that allows both Guest checkouts and registered user checkouts, how will you handle the 2 different customer groups?
Do you store both groups in the same table customers which has a foreign key customer_group_id pointing to another table customer_groups? In this case, will you worry about duplicate guest checkouts "polluting" the customers table?
How will the information captured for the 2 customer groups be different? I am thinking the difference is that the guest checkout customers will not have a password thats it.
I store customer information directly in the order rather than rely on the information in the customer record. That does a couple things:
I don't have to have a guest user in the customer database
If my customer information changes, or if a customer wants to ship one item to one place, and another item to another place the information about the order will still be correct.
I view order information as historical data. It should not change because something else in your database changes. For example if I order something from you, and at some later time I move and update my billing and shipping information, you should still know that the previous order was billed and shipped to the previous address. If you rely on the relationship between the customer and the order to retain bill to and ship to information, Once I move and update my profile, you think you shipped to my new address. You may not see that as an issue, but it will be.
You can still get the current information from the customer record to populate the fields on the order if the customer has an account. For a guest, he has to type it every time.
The common entity is a Checkout. The guest checkout would be a null FK link on the checkout entity to a registerd user entity.
I'm working on my final project for an intro to Access DB class. My assignment is a general "Create a DB with at least 3 tables, of which 2 are linked," with some specific requirements for types of tables (customer relations, financial management, product/service-related data).
I decided to create a database for a fictional airline. I need to track financial information, particularly the sale of tickets. I have a tblFlights table that includes a BaseFare field, a tblAirports table that includes airport fees and airport taxes and a tblInvoice table that currently only has invoice number and customer ID fields in it. I suppose that I would use a report to generate an actual invoice, not a table, right? So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
I suppose that I would use a report to generate an actual invoice, not a table, right?
Yes, use a report.
So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
Well, I suppose some industries might be able to get an airline to send them in invoice, but I've never heard of that myself. In my experience, you pay first, then they give you the ticket. So I'd expect a table of tickets, which would identify the flight, the seat (or its equivalent), the person's name, and something to indicate that it's paid (a Boolean flag, a price, something like that).
Assume a simple database for hotel reservations with three tables.
Table 1: Reservations
This table contains a check-in and check-out date as well as a reference to one or more rooms and a coupon if applicable.
Table 2: Rooms
This table holds the data of all the hotel rooms with prices per night and number of beds.
Table 3: Coupons
This table holds the data of all the coupons.
Option #1:
If you want to get an overview of the reservations for a particular month with the total cost of each reservation, you'd have to fetch the reservations, the rooms for each reservation, and the coupon (if one is present).
With this data, you can then calculate the total amount for the reservation.
Option #2:
However, there is also another option, which is to store the total cost and discount in the reservation table so that it is much easier to fetch these calculations. The downside is that your data becomes much more dependent and much less flexible to work with. What I mean is that you have to manually update the total cost and discount of the reservation table every time you change a room or a coupon that is linked to a reservation.
What is generally recommended in terms of performance (option #2) version data independence (option #1).
UPDATE:
It is a MySQL database with over 500 000 rows (reservations) at this point, but is growing rapidly. I want to optimize database performance at an early stage to make sure that the UX remains fast and responsive.
Let me start to answer this with a story. (Somewhat simplified.)
2011-01-01 I reserve a room for two nights, 2011-03-01 and 2011-03-02. You don't tell me which room I'll get. (Because you don't know yet which room I'll get.) You tell me it will cost $40 per night. I have no coupons. You enter my reservation into your computer, even though you're already fully reserved for both those nights. In fact, you already have one person on the waiting list for both those nights. (Overbooking is a normal thing, not an abnormal thing.)
2011-01-15 You raise the rates for every room by $5.
2011-02-01 I call again to make sure you still have my reservation. You confirm that I have a reservation for two nights, 2011-03-01 and 2011-03-02, at $40. (Not $45, your current rate. That wasn't our deal. Our deal was $40 a night.)
2011-02-12 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. You still don't yet have a room you know for certain that I'll be able to check in to. The other person from the waiting list now has a room; I'm still on the waiting list.
2011-02-15 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. Now I have a room.
2011-03-01 I check in with a coupon.
You can store the "current" or "default" price with each room, or with each class of
rooms, but you need to store the price we agreed to with my
reservation.
Reservations don't reserve rooms; they reserve potential rooms. You
don't know who will leave early, who will leave late, who will
cancel, and so on. (Based on my experience, once in a while a room will
be sealed with crime scene tape. You don't know how long that will last, either.)
You can have more reservations than room-nights.
Coupons can presumably appear at any time before check out.
If you want to get an overview of the reservations for a particular
month with the total cost of each reservation, you'd have to fetch the
reservations, the rooms for each reservation, and the coupon (if one
is present).
I don't think so. The price you agreed to should be in the reservation itself. Specific rooms can't resonably be assigned until the last minute. If there's one coupon per reservation, that might need to be stored with the reservation, too.
The only reporting problem is in making sure your reports clearly report how much expected revenue should be ignored due to overbooking.
The response of your answer depends of the size of your database. For small database option #1 is better, but for huge database option #2 is better. So if you could say how many rows you got in table, and the database used (oracle, sqlserver etc.) you will have a more precise answer.
You can add a table holds the data of the rooms`s historical prices and reason for change.
Table 2 only records the latest price.