Wow! This looks very nice.
I hope I won't botch it too much. These are my suggestions:

/*trim dinining room table and move capacity related fields
to a new table, suggested below as TBL_DININGTABLE. Also,
add INT_BUILDING to identify the location of the dinign
room*/

TBL_DININGROOM
Table Notes
Field Name Datatype Length Scale Not Null Notes
INT_DININGROOM INT64 8 0 Not Null
INT_BUILDING INT64 8 0 Not Null
STR_NAME VARCHAR 50 0 Not Null
STR_DESC VARCHAR 100 0 Nullable
Foreign key Dependencies
Local Relies Upon Remote
Foreign key Dependants
Remote Relies Upon Local
TBL_DININGRESERV.INT_DININGROOM --> INT_DININGROOM
TBL_INT_BUILDING.INTBUILDING --> INT_BUILDING


TBL_DININGTABLE
Table Notes
Field Name Datatype Length Scale Not Null Notes
INT_TABLE INT64 8 0 Not Null
INT_DININGROOM INT64 8 0 Not Null
INT_CAPACITY LONG 4 0 Nullable
IBL_OVERFLOW LONG 4 0 Nullable
INT_MAXCAP LONG 4 0 Nullable
Foreign key Dependencies
Local Relies Upon Remote
Foreign key Dependants
Remote Relies Upon Local
TBL_DININGROOM.INT_DININGROOM --> INT_DININGROOM

/*some dining rooms/areas may be operating only during
certain hours/day, for instance 365 minus Christmas etc.
Defining closing hours only, instead of opening hours may
be more useful as exceptions would not require extra fields
or tables, the premise being that the dining room is open
more often than it is closed. Therefore, the room is open
at any time outside the range between TST_CLOSE_TIME_START
and TST_CLOSE_TIME_END.

If closing period may be defined as INT_RECURRING then i
may make sense to use an INTEGER denoting the value of
reccurrence, i.e 0 might mean weekly, 1 monthly etc. These
values may be also defined in a separate table holding
String description of the reccurence period. Still thinking
about that one though, suggestions welcomed */

TBL_DININGROOMTIMES
Table Notes
Field Name Datatype Length Scale Not Null Notes
INT_DININGROOM INT64 0 0 Not Null
TST_CLOSE_TIME_START TIMESTAMP 0 0 Not Null
TST_CLOSE_TIME_END TIMESTAMP 0 0 Not Null INT_RECURRING
SMALLINT 0 0 Not Null
Foreign key Dependencies
Local Relies Upon Remote
Foreign key Dependants
Remote Relies Upon Local
TBL_DININGROOM.INT_DININGROOM --> INT_DININGROOM

-------------------------
Also, I am looking at TBL_CONTACT. I am tempted to suggest
fields showing times when a particular contact is
available. This is for people on the move, people with more
than two address, seasonals etc. This is used a lot in
clubs and spas. Not sure about our design here. We seem to
be doing a hotel with a touch of club.?


--- Nigel Weeks <nweeks@...> wrote:

>
> > The latter, please. Nothing gets to be "old news"
> quicker
> > than an email -
> > except possibly a database schema. :-)
> >
>
> Something to read over when you next have a
> hot coffee with double the sugar you normally have...;-)
>
>

http://groups.yahoo.com/group/Firebird-general/files/CodeSamples/

>
> You'll find the latest .sql file, and a .html document
> showing all the
> linkages between tables.
> Shall we add more to the design, or put out the challenge
> for interfaces
> onto it...
>
> Nige.
>
> Nigel Weeks
> Tech Support & Systems Developer
> nweeks@...
> www.examiner.com.au
> 71 - 75 Paterson Street
> Launceston
> Tasmania 7250
> Australia
> Phone: 03 6336 7234
>
>
>
> Community email addresses:
> Post message: Firebird-general@yahoogroups.com
> Subscribe:
> Firebird-general-subscribe@yahoogroups.com
> Unsubscribe:
> Firebird-general-unsubscribe@yahoogroups.com
> List owner: Firebird-general-owner@yahoogroups.com
>
> Shortcut URL to this page:
> http://www.yahoogroups.com/community/Firebird-general
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com