Table Structure

S

Steve

I'm attempting to build my first database. I want to use it to manage a low
income housing project. I have to track some of the following:

Prospective Tenant/Tenant info
Applications/Waiting List (It is possible that a prospective tenant could
submit an application this month and get turned down. Then they might
submit another one next month)
Contacts related to each Application & Tenant (Letters sent, Phone calls
made, etc.)
Occupancies related to Prospective Tenant/Tenant
Etc.

I think I need to have a table for Prospective Tenant/Tenant and another for
Applications that they submit. This would be a one to many relationship
with the Applications table on the many side. I'll need another table for
Contact that is on the many side of a one to many relationship with the
Application table. I would want to inforce Referential Integrity because I
don't want to find applications without tenants or contact records that
aren't associated to an application.

Am I getting it straight? The way I understand it everything that could
posibly be repeated like Applications, Occupancy, Contacts, etc. need to be
in a separate table. Is this right? Would I want to check the Cascade
Update and Delete boxes when setting up the relationships? I don't really
understand this part.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top