Re: Applicants and Subtypes

This looks like an elaborately hidden homework assignment, and I'm sorry for saying that if this is legit, but anyway...

One possibility relies primarily on programming rather than design changes. For example, assuming you can track the Inquirer's PK somehow (you'd need to keep track of each person consistently throughout no matter how you do thisone  way is to give each inquiring person the ID number and ask them to use it in future correspondence), you could create an entry in the Apply table with the Inquiry ID should the person actually apply. And so on if the person enrolls, etc...

The trickier part is getting the information out when you're done, as some applicants never inquired, etc. It depends on what reports you'll need.

I haven't given this a lot of thought, but I suspect there are many ways to solve this. I think it may be helpful to work this one out backwards, taking implementation issues into consideration while designing.

If it's not a homework assignment, it should be!

<leroyg_at_my-deja.com> wrote in message news:87nc6s$64d$1_at_nnrp1.deja.com...
> I am trying to analyze a legacy system with the following core
> structure:
>
> student(id (pk), last_name, first_name, middle_name, etc.)
> inquiry(id (pk), term (fk), inquiry_date, etc.)
> apply(id (pk), term (fk), apply_date, status (fk), etc.)
>
> where student is a supertype and inquiry and apply are subtypes and term
> and status reference lookup tables. A student may first inquire and then
> apply, inquire and never apply, or apply without having inquired.
>
> Is there another way to structure this setup so that an inquiry is
> simply another stage of the application process, in order to better
> gauge how many inquiries become applicants? Since there are usually
> many more inquiries than applicants, I am trying to design the most
> efficient database that will track essential information without being
> redundant (i.e., without having separate inquiry and application tables,
> and without have inquiry and application name data appearing in two
> tables). And if items like country_of_birth are tracked for applicants
> but not for inquiries, should that data be stored in the supertype
> (student), or in the apply table?
>
> Also--and this may be purely a business rule issue--should each person
> who applies also count as a inquiry by definition (inquired means
> requested a printed application)?
>
> Any help would be greatly appreciated.
>
> Thanks,
> Leroy
>
> --
> Leroy Gonzalez
> leroyg_at_my-deja.com
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Tue Feb 08 2000 - 00:00:00 CET