Applicants and Subtypes
Date: 2000/02/07
Message-ID: <87nc6s$64d$1_at_nnrp1.deja.com>#1/1
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 Mon Feb 07 2000 - 00:00:00 CET