| | |
Reservation diving
Please support our Database Design advertiser: PostgreSQL or MySQL? Compare and contrast the two most popular open source databases
Thread Solved |
•
•
Join Date: Jan 2008
Posts: 6
Reputation:
Solved Threads: 0
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.
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.
Human mind has no limits, however that doesn't cover up the fact that human itself is weak.
•
•
Join Date: Jan 2008
Posts: 6
Reputation:
Solved Threads: 0
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.
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.
Human mind has no limits, however that doesn't cover up the fact that human itself is weak.
•
•
Join Date: Mar 2008
Posts: 5
Reputation:
Solved Threads: 0
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?
Member
----------
MemberId
Name
Gender
Address
etc
Reservation
--------------
ReservationID
Departure date
Arrival date
Number of nights
Name
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?
•
•
Join Date: Jan 2008
Posts: 6
Reputation:
Solved Threads: 0
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)
Human mind has no limits, however that doesn't cover up the fact that human itself is weak.
•
•
Join Date: Jan 2008
Posts: 6
Reputation:
Solved Threads: 0
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.
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. Human mind has no limits, however that doesn't cover up the fact that human itself is weak.
![]() |
Other Threads in the Database Design Forum
- Previous Thread: populating DataGrid using Recorset
- Next Thread: ERD for Warehouse?
| Thread Tools | Search this Thread |





