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?
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 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.
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.
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?
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)
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.