Link to home
Start Free TrialLog in
Avatar of Evan Cutler
Evan CutlerFlag for United States of America

asked on

Data Modeling Table Relationships

Greetings,
I'm creating a Data Model, and I'm trying to get it to 3NF.
I keep reasoning myself into a circular model, and I don't want that.

That being said, I was hoping to get some other opinions.
THe attached data model completes the list of data facts I require.
I'm having issues setting the relationships.

Here's the facts I know:
1.  There are multiple locations
2. Each location has 1 or more dates
3. Each Location has 1 or more spaces
4. Each space requires a reservation
5. Each reservation is a space per date per location

Each table has the dataparts I require to move forward.
Any recommendations on how to make this data model fit better would be greatly appreciated.

Thank you.
Evan
datamodel.pdf
ASKER CERTIFIED SOLUTION
Avatar of Kent Olsen
Kent Olsen
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Evan Cutler

ASKER

Hi Kent,
Thanks so much...

Hey, in Reservations, is Date field a FK to HotelDates?
Apart from the showdate in your reservation table (which probably is derived from the ShowDates reference), I don't see any problem with 3NF here ... assuming that multiple reservations for the same date and space are allowed, you need the additional PK field in the reservations table. If only one reservation for a date/space combination can be made, drop the PK field and you should be fully normalized to 3NF there ... assuming you have 1NF and 2NF already, the only additional requirement is that no fields may be derivable from other means than the primary keys, which isn't the case for the other data fields.

So, adding the 1:n relationships between the location and both dates and spaces, and 1:n between both dates and spaces and the reservations table should solve your design ...

Also, from personal experience, while normalization is a good idea, there are occasions where full normalization may cause performance or design issues in other places, so using it as a starting point is good, but don't treat it as a religion ... ;) If you can get your program to work better with slight tweaks to the data model, weigh the pros and cons and go with the solution that is the better one overall...
>> Hey, in Reservations, is Date field a FK to HotelDates?

That depends on your implementation.  If HotelDates contains all of the dates when the Hotel is open (or accepting reservations), a Foreign Key relationship exists.  If the table contains the dates when the Hotel is closed, full, (not accepting reservations for any reason) there is a "backward" relationship, but no real foreign key.  And if the table contains a range of dates (start_date -> end_date) of either accepting or not accepting reservations, there is no foreign key.  BUT, they all resolve with the correct SQL.  The difference is that you have to code the SQL to the problem, where if there is a FK relationship, the DBMS maintains it for you.


Kent
Thanks.
This helped alot.