well, you need to define your entities, which will move some groups of
fields into their own tables. those tables will be the "parent" tables in a
1:n relationship with your tblVitals (data that describes the deceased
person). examples:
tblCoroners (all the fields that describe a coroner)
tblCemeteries (fields describing the cemetery)
tblCrematories (ditto previous)
tblInstitutions (the placed where the person died, i'm guessing)
tblMedicals (fields describing the person who signed the death certificate;
i'm assuming that is the purpose of the fields prefixed with "Medical_")
i realize that the above tables may include records that have a relationship
with only one record in tblVitals - but a lot of your business is probably
local, and many of those parent records *will* be associated with multiple
records in tblVitals.
some other groups of fields should be subclassed into their own tables
(because they will not apply to all deceased persons), which will then
correctly have 1:1 relationships with tblVitals. examples:
tblMarriages
tblMilitaryService
tblLuncheons
tblInjuries
and a couple groups of data *could* have a n:1 relationship with tblVitals,
so should be in their own separate "child" tables. example:
tblNextOfKin
tblVisitations
also, since you have so many tables that include city, state, zip (and some
with county also), you might want to consider investing in a national
zipcode data table. (you can get that data from the USPS, of course; and
there are also companies that sell the data, with varying levels of
additional data, such as
http://www.zipcodedownload.com/) you could use the
zip code table as a supporting table, enabling you to save only a single
foreign key into your other tables - rather than city, county, state, zip
code data fields in each table. i also wonder if you need a way to
accommodate foreign cities/countries info for those persons who were born
and/or lived and/or died outside the US.
the above suggestions aren't meant to be exhaustive, and may not always be
on target (if i've made incorrect assumptions). but hopefully they'll give
you some ideas on how to approach your data, and issues you may need to
consider.
hth
