Reservation diving

[tarnita]

Hello Everybody!!i am confused to do the database design for diving reservation.
Please helpp me!! Thank you.

[xasthur]

please tell what u have thought(or done) so far, maybe i can help then. Im learning DB this semester, thus quite in ERs and relational schemas :D

[tarnita]

I have thought that reservation table, users table, ticket table, invoice table, package table, room rates table and payment table.
However, i'm focus on customization package where allow the customer to customize the modify the package. So, do you have any better idea than me?

[xasthur]

well,
actually...i got a lil confused here;
did you mean a general reservation design here? that can be used for any application including a reservation process? or something more special? Can you please be more specific?
your idea looks ok, u can let customers customize the package with providing appropriate attributes for package table, and then relate that table with each customer.

[tarnita]

Actually, i want to focus more on customization package. But,i'm little confuse what are the entity name and attribute for package that has been customized. I also want to do reservation design. Like the customers do payment,reserve and customize.

[xasthur]

hey, sorry for the late answer.
well...the name, is not really important, it should be anything related and meaningful, for the entity types.
In my opinion, do a package entity, with attributes you would like to use. Umm, i dont know if i could help you about attribute names yet, i mean, did u really think on ur design? I mean like, okay, customers can do this this and this, and they can customize this and that..my advise to you is to think carefully first bout what entities could able to do what in your DB design.
For example, as much as i understood, you should have a package entity, a customer entity, a payment and maybe a reserve entity...some attributes might be name, phone, etc of the customers, umm a customerID for key attribute for example. for package entity u can have whatever attributes u want for the customers so they can change, i guess in this case, those attributes will be multivalued. you should think broad and design an ER diagram maybe(entity-relationship diagram), then u will be ready for the mapping phase, where you will relate those entities and make tables.

[tarnita]

ya..i have thought my design already:
Member
----------
MemberId
Name
Gender
Address
E-mail
etc

Reservation
--------------
ReservationID
Departure date
Arrival date
Number of nights
Name
E-mail
Address
Total Cost

Ticket
--------
TicketID
CustName
Date

Invoice
---------
InvoiceID
CustName
IssueDate
AccountNo
Total

Payment
------------
PaymentId
Date
AccountNo
Payment type
Total

Room rates
--------------
RoomtypeID
Room type
Room rates
numberofnights
Season

Package
-----------
PackageID
PackageName
PackageCustomized

Those tables, i haven't normalized. The thing that makes me confuse is what the table that has relation with package table. I mean to store all the list that customer can customize.
Do u have any idea?

[xasthur]

hmm, having a look at that tables, im definitely sure that u should relate member with package..apart from that maybe with payment, and reservation, and room also. but in this case your design will be too complicated ( hard to track and potentially slow, because of n-ary relationships) but if u can handle it, there will not be a problem. (attributes like room-type, payment-type, no_of_nights would reference to actual entities from the package table)

[tarnita]

Thank you for your advice. Can you help me to do normalization up to 3rd NF?

[xasthur]

hey,
no problem.
by the way im really sorry because i write back late, im just kind of busy these days because of the school.
Sure thing, i would like to help you out with normalization but im not really good at it yet because we are learning it on Database Management course nowadays :) but like i said i would try to help.