A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Confusing Relationships - Addendum



 
 
Thread Tools Display Modes
  #1  
Old April 2nd, 2006, 02:08 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

Hi all,

I'm starting a new thread because i did not get response for my latest
posting in the other thread (Confusing relationships), so i started a new
thread. Maybe the post went unnoticed among all the replies etc..

Anyways, heres the expcerpt from the previous thread..
-------
I'm Back,

This time, i have the completed product with me. I thank all of you for
providing invaluable help.

Find it here -- http://members.westnet.com.au/mukund/insurance.zip

This is no way the finished product, but i'm nearly there. I need to do a
fair bit with regards to reports and stuff, also have included a switchboard
(autogenerated) just for the heck of it.

Please review it and let me know...

Thanks
kingnothing
-----------------
PS: There will be no introduction required for people following the old
thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships


Thanks Again..
kingnothing

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/200604/1
  #2  
Old April 2nd, 2006, 02:50 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

While this database probably is interesting for you, most of us see several
databases each day. So you might get some specific help with a specific
question, but you may not get any answers just asking people to download and
comment on your database.

BTW, you might find it easier to find and follow your threads by using a
newsreader such as Outlook Express rather than a web interface. Your ISP's
news server is shown on this page:
https://secure1.wn.com.au/autoconfig/default.aspx
or you could use the Microsoft one:
news.microsoft.com

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"kingnothing via AccessMonster.com" u18754@uwe wrote in message
news:5e2d0bbaf4d6d@uwe...
Hi all,

I'm starting a new thread because i did not get response for my latest
posting in the other thread (Confusing relationships), so i started a new
thread. Maybe the post went unnoticed among all the replies etc..

Anyways, heres the expcerpt from the previous thread..
-------
I'm Back,

This time, i have the completed product with me. I thank all of you for
providing invaluable help.

Find it here -- http://members.westnet.com.au/mukund/insurance.zip

This is no way the finished product, but i'm nearly there. I need to do a
fair bit with regards to reports and stuff, also have included a
switchboard
(autogenerated) just for the heck of it.

Please review it and let me know...

Thanks
kingnothing
-----------------
PS: There will be no introduction required for people following the old
thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships



  #3  
Old April 2nd, 2006, 09:34 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

Hi Allen,

Thanks for the reply..

I wasnt at my computer to use NNTP, so i posted on the web.

Anyways, I'm still seeking answer to a particular issue only (Realtionships).
Just wanted to make sure that i had incorporated all the solutions that the
posters had suggested.

Also, According to Vincent Johns and other people who had replied to the
previous thread, i posted the db on the web for review and comments.

Cheers

kingnothing

Allen Browne wrote:
While this database probably is interesting for you, most of us see several
databases each day. So you might get some specific help with a specific
question, but you may not get any answers just asking people to download and
comment on your database.

BTW, you might find it easier to find and follow your threads by using a
newsreader such as Outlook Express rather than a web interface. Your ISP's
news server is shown on this page:
https://secure1.wn.com.au/autoconfig/default.aspx
or you could use the Microsoft one:
news.microsoft.com

Hi all,

[quoted text clipped - 24 lines]
thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships


--
Message posted via http://www.accessmonster.com
  #4  
Old April 3rd, 2006, 01:21 AM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

I was planning to look at the posted database, but haven't done so yet,
for at least 2 reasons.

(1) I haven't finished an answer to someone else, so that has
priority over this one, which didn't ask a specific question.
(2) It's not in Access 2000 format, so to open it for examination,
I'll have to copy it to my laptop computer, which has Access 2003, open
it in Access 2003, save it in Access 2000 format, copy it back, and open
it in Access 2000... but that will take more time than I want to spend
right now. (You might consider saving example copies in Access 2000
format.)

-- Vincent Johns
Please feel free to quote anything I say here.

kingnothing via AccessMonster.com wrote:

Hi Allen,

Thanks for the reply..

I wasnt at my computer to use NNTP, so i posted on the web.

Anyways, I'm still seeking answer to a particular issue only (Realtionships).
Just wanted to make sure that i had incorporated all the solutions that the
posters had suggested.

Also, According to Vincent Johns and other people who had replied to the
previous thread, i posted the db on the web for review and comments.

Cheers

kingnothing

Allen Browne wrote:

While this database probably is interesting for you, most of us see several
databases each day. So you might get some specific help with a specific
question, but you may not get any answers just asking people to download and
comment on your database.

BTW, you might find it easier to find and follow your threads by using a
newsreader such as Outlook Express rather than a web interface. Your ISP's
news server is shown on this page:
https://secure1.wn.com.au/autoconfig/default.aspx
or you could use the Microsoft one:
news.microsoft.com


Hi all,


[quoted text clipped - 24 lines]

thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships



  #5  
Old April 3rd, 2006, 02:03 AM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

Thats ok Vincent,

Just thought that the post was lost between all the replies...theres no hurry
to reply...

I really appreciate your time and effort to help people. Thats the good thing
about this site..people actually reply, unlike other places (names skipped
intentionally) where the gurus consider it below their status to answer to
newbies...

Cheers,

kingnothing

Vincent Johns wrote:
I was planning to look at the posted database, but haven't done so yet,
for at least 2 reasons.

(1) I haven't finished an answer to someone else, so that has
priority over this one, which didn't ask a specific question.
(2) It's not in Access 2000 format, so to open it for examination,
I'll have to copy it to my laptop computer, which has Access 2003, open
it in Access 2003, save it in Access 2000 format, copy it back, and open
it in Access 2000... but that will take more time than I want to spend
right now. (You might consider saving example copies in Access 2000
format.)

-- Vincent Johns
Please feel free to quote anything I say here.

Hi Allen,

[quoted text clipped - 31 lines]
thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/200604/1
  #6  
Old April 3rd, 2006, 07:21 AM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

I have now copied your file to my other computer (or, at least, to the
flash memory that I hang around my neck like a dog tag, and that's a big
step closer to the laptop) and will look at it when I get a chance.

-- Vincent Johns
Please feel free to quote anything I say here.

kingnothing via AccessMonster.com wrote:

Thats ok Vincent,

Just thought that the post was lost between all the replies...theres no hurry
to reply...

I really appreciate your time and effort to help people. Thats the good thing
about this site..people actually reply, unlike other places (names skipped
intentionally) where the gurus consider it below their status to answer to
newbies...

Cheers,

kingnothing

Vincent Johns wrote:

I was planning to look at the posted database, but haven't done so yet,
for at least 2 reasons.

(1) I haven't finished an answer to someone else, so that has
priority over this one, which didn't ask a specific question.
(2) It's not in Access 2000 format, so to open it for examination,
I'll have to copy it to my laptop computer, which has Access 2003, open
it in Access 2003, save it in Access 2000 format, copy it back, and open
it in Access 2000... but that will take more time than I want to spend
right now. (You might consider saving example copies in Access 2000
format.)

-- Vincent Johns
Please feel free to quote anything I say here.


Hi Allen,


[quoted text clipped - 31 lines]

thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships



  #7  
Old April 3rd, 2006, 07:35 AM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

No worries, Thanks

kingnothing

Vincent Johns wrote:
I have now copied your file to my other computer (or, at least, to the
flash memory that I hang around my neck like a dog tag, and that's a big
step closer to the laptop) and will look at it when I get a chance.

-- Vincent Johns
Please feel free to quote anything I say here.

Thats ok Vincent,

[quoted text clipped - 31 lines]
thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships


--
Message posted via http://www.accessmonster.com
  #8  
Old April 6th, 2006, 09:53 PM posted to microsoft.public.access.tablesdbdesign
external usenet poster
 
Posts: n/a
Default Confusing Relationships - Addendum

kingnothing,

I had written a few comments in general about your Tables, then
decided that much of what I wanted to say actually related a lot to
individual fields. So, I decided to organize them by field (but, as
you'll see, several of them are suggestions about other Tables that I
think you would find useful). It's kind of a long list, but all the
fields within a Table are listed below that Table's name (except that I
called [Policy Type] just [Type], to make the list a bit shorter).

============================
Table: Address

Field
Type Size
Comments
--------------------------------------

Address_ID
Long Integer 4
Primary key, identifying the mailing
address of one or more [Person]s in the
database.

Address Type
Text 50
What is this? If there are only a few
such types, I suggest putting a list of
them into another Table, and linking to
that Table.

Street Address
Text 50
If you need 50 bytes for [Suburb], are
you sure that 50 will be enough for
this? Street names are often longer
than city names.

Suburb
Text 50

State
Text 50
I suggest either linking to another
Table (such as my suggested [State]
Table) or just stuffing the 3-letter
name here.

Country
Text 50
I suggest either a link or a 2-letter
country abbreviation here, not an
entire name.

Pin Code
Text 50
What use does an [Address] have for a
Personal Identification Number Code?
(Or does "Pin" mean something else,
such as postal code? If so, it wasn't
clear to me; I'd suggest a name like
[PostalCode].)

Contact_ID
Long Integer 4
Link to [Person].

Spouse_ID
Long Integer 4
Link to [Person].

Child_ID
Long Integer 4
This allows at most one contact, at
most one spouse, and at most one child
at each address. I think this is
backwards; I would put an [Address_ID]
field into [Person] instead, or, if you
really need a many-to-many
relationship, have a 3rd Table linking
various persons with various addresses,
perhaps with related information such
as when the person moved there and when
he moved away.


============================
Table: Insurance

Field
Type Size
Comments
--------------------------------------

Insurance_ID
Long Integer 4
Primary key, identifying an insurance
policy.

Policy Number
Text 50
Wouldn't most policy numbers be more
like 15 characters long, instead of 50?

Insurance Company
Text 50
I imagine you deal only with a few
companies, and would want related stuff
like contact information for each of
them. So I suggest that that be put
into an [Insurer] Table, and that this
field link to that Table.

Policy Owner
Text 50
Why is [Insurance].[Policy Owner] a
Text field??? I would make this be a
link (foreign key) to some record in
the [Person] Table.

Life Insured
Text 50
It's not obvious what information you
keep here.

Sum Insured
Currency 8
Is this the maximum amount to be paid
if an event listed in the policy occurs?

Premium
Currency 8
Is this a monthly premium?

Premium Mode
Text 50
As there appear to be only 2 possible
values for this, I suggest moving the
list of choices to another Table and
linking to that Table. Or, you could
make this a Yes/No field, with, for
example, Yes = Annual and No = Monthly
and changing the name to
[AnnualPremium?].

Start Date
Date/Time 8
Is this the date at which premiums
first become due, or at which coverage
begins? (Maybe those are the same
date.) In any event, you might want to
somewhere clarify exactly what this
means.

Beneficiaries
Text 50
If this is intended to be the name of
some human being, I suggest using a
link to [Person] or to a Table that
links to [Person]. Otherwise, it's not
obvious what this is supposed to mean.

Renewal Date
Date/Time 8

Comission Upfront
Currency 8

Comission Upfront Percent
Long Integer 4
Must this really be an integer? I
suggest using some data type, such as
Decimal, that allows fractions.

Comission Ongoing
Currency 8
I assume that this is well defined in
your system. Somewhere in your
documentation you should include a
detailed definition, I think.

Comission Ongoing Percent
Long Integer 4
I suggest a data type that permits
fractions.

Monthly Benefit
Currency 8
Can this ever change? If so, how will
you account for that? I think you'd
need to record the date and new value,
each time a change occurs.

Policy Name
Text 50
You already have an [Insurance].[Policy
Number] field. Does this one duplicate
its functions? If so, I suggest
deleting one.

Policy Detail 1
Text 60
If there are only a few possible values
for this, I suggest putting the
possibilities into another Table and
linking to it.

Policy Detail 2
Text 60
How does this differ from
[Insurance].[Policy Detail 1]? If, as
I suspect, there is no essential
difference in data type, you have here
a "repeating group", which can lead to
lots of headaches in database
maintenance. I suggest moving all 5 of
these fields to another Table, and
linking them to this policy via the
value in the [Insurance].[Insurance_ID]
field.

Policy Detail 3
Text 60
(Repeating group, I assume. If not,
its name is very misleading, and I
suggest changing it.)

Policy Detail 4
Text 60
(repeating group)

Policy Detail 5
Text 60
(repeating group)

Contact_ID
Long Integer 4
Is this a reference to the person whose
injury (e.g.) is the event described in
the policy? Or else is it the person
responsible for paying the premiums?
Or are they always the same person (I
assume not)? A more suggestive name
than "Contact" (such as "Insured")
might clarify this, though if "Contact"
is the designation used in the
insurance policy contract, I guess I
would follow the language used in the
contract.

Spouse_ID
Long Integer 4
I notice that you include a "Spouse"
but no "Beneficiary". If the spouse is
not the beneficiary, why do you need to
record any information about the
spouse? If this field is intended to
identify a beneficiary, then I suggest
that its name be changed to reflect its
function.

Child_ID
Long Integer 4
It appears that, to insure more than
one child, one must acquire a separate
policy for each one. Is that also
necessary if one wishes to cover both a
child and a spouse? The design doesn't
preclude covering both child and spouse.


============================
Table: Misc

Field
Type Size
Comments
--------------------------------------

mSuburb
Text 50
Unless they're re-used frequently,
these values might just as well be
expressed as ordinary text inside the
[Address].[Suburb] field.

mID
Long Integer 4
The [Misc] Table looks like an effort
to assign numbers to names, perhaps in
an effort to save space. I suggest
that using a separate Table for each of
these fields, with a suitable Table
name and primary key, would make the
design easier to understand and
remember. For example, see my (new,
unused) Table of [States].

mState
Text 3
It may be a waste of effort to look
these up, instead of just storing the 3-
letter name in a field.

mCountry
Text 50
ICANN has defined 2-letter names for
lots of countries and similar regions;
you might want to include a Table
containing those. You could use the 2-
letter name as its primary key.

mMarriageStatus
Text 50
I suggest putting these into a separate
Table. Incidentally, how does this
relate to insurance? You might want to
add fields that you can use to limit
the types of insurance a person with a
given marriage status can have.

mAdressType
Text 50
This looks like a duplication of
[Address].[Address Type].

mTitle
Text 50
I suggest putting these into a separate
Table.

mSex
Text 50
I suggest putting these into a separate
Table, perhaps with a primary key whose
values are "M" or "F".

mPremium Mode
Text 10
I suggest putting these into a separate
Table, perhaps with a primary key whose
values are "Y" or "M".


============================
Table: Person

Field
Type Size
Comments
--------------------------------------

Person_ID
Long Integer 4
Primary key.

Title
Text 50
This seems kind of long for typical
titles, unless you're including
royalty. But even so, I suggest moving
the list of choices to another Table
and linking to that Table.

First Name
Text 50

Middle Name
Text 50

Surname
Text 50

Preferred Name
Text 50

Sex
Text 50
You probably don't need to allow 50
characters for this. You might be able
to get by with one (such as "M" or "F")
and allow it to be null if unknown.

DOB
Date/Time 8
I assume this means "date of birth",
but it's not really specified
anywhere. At least the Description
field in Table Design View should
specify what it means.

Annual Salary
Text 50
Can the amount paid by the policy
depend on this? (Otherwise, what's the
point of maintaining it?) Since it's
likely to change, I suggest including a
field identifying the date when this
was last updated.

Smoking Status
Yes/No 1
Does this need to be updated at times?
Mark Twain claimed that he quit smoking
numerous times. Do you need a date at
which this was effective? Or is its
value "Yes" if the insured person has
ever smoked at least one cigarette?

Marital Status
Text 50
There can't be very many possible
values for this, I think. I suggest
using a link to another Table.

Mobile Phone
Text 50
This and the other phone numbers are
short enough that, even though they
form a repeating group (and are
therefore candidates for being moved to
a Table of telephone numbers), it
probably won't cause a lot of trouble
to just leave them here. But who uses
a 50-digit phone number?

Business Phone
Text 50

Home Phone
Text 50

Fax
Text 50

Email
Text 50

Notes
Memo 0
OK, but if the memo becomes really
long, you might want to include a
reference to a paper file.

Mailing List
Yes/No 1
If this is "Yes", what does that mean?
That it's OK to send advertising
materials to this person? You might
want to change the name to suggest what
kind of list this is.

Position
Text 50
Is this a job title? Where do you need
to use it? You might include this in
the [Address] Table as part of the
mailing address, if that's where you
need to send notices.

Company
Text 50
Is this an employer's name? This looks
like something that belongs in
[Address].

Spouse_ID
Long Integer 4

Child_ID
Long Integer 4
Your [Persons] Table allows AT MOST one
child (probably too restrictive, unless
you're in China). You can never record
more than one child with this design.


============================
Table: State

Field
Type Size
Comments
--------------------------------------

State
Text 3
Primary key, identifying a state.
This Table is an example of how I would
organize the state names, instead of
putting them in [Misc]. Actually,
since these names are pretty short, I
just used these values as the primary
key, instead of using a 4-byte number.

TaxRate
Decimal 16
This is just an example of the kind of
information that you might include that
would relate to a state. (I don't even
know if these states impose ad valorem
taxes.)


============================
Table: Type

Field
Type Size
Comments
--------------------------------------

Insurance Type ID
Long Integer 4
Primary key to [Insurance Type] Table,
identifying a type of standard policy.

Insurance Type
Text 55
Some of the types in [Insurance Type]
seem to overlap more than others. Do
you want to allow someone to have both
"Income Protection: Accident Benefit:
Upto 65" and "Income Protection:
Accident Benefit: Upto 60"? But it might
make sense to have both one of these
and a "Children's Trauma" policy. The
insurance company probably already has
a system for categorizing policies; you
might be able to use that same system.

Well, that's it (for now). As I assume you're aware, there are many
ways to organize a relational database, but some involve more work than
others. The purpose behind my comments, generally, is to reduce the
needed work. Good luck.

-- Vincent Johns
Please feel free to quote anything I say here.

kingnothing via AccessMonster.com wrote:

No worries, Thanks

kingnothing

Vincent Johns wrote:

I have now copied your file to my other computer (or, at least, to the
flash memory that I hang around my neck like a dog tag, and that's a big
step closer to the laptop) and will look at it when I get a chance.

-- Vincent Johns
Please feel free to quote anything I say here.


Thats ok Vincent,


[quoted text clipped - 31 lines]

thread...but for others, please refer --
http://www.accessmonster.com/Uwe/For...-relationships



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
confusing relationships kingnothing via AccessMonster.com Database Design 28 March 31st, 2006 01:50 AM
Moving Relationships Between Databases kh Running & Setting Up Queries 4 February 23rd, 2006 05:46 PM
Using Relationships window [email protected] Database Design 11 October 2nd, 2005 06:44 PM
Confused about one-to-many or many-to-many relationships CAD Fiend Database Design 4 July 7th, 2005 03:38 PM
Mixed up with Relationships..help! KrazyRed New Users 3 January 26th, 2005 05:03 AM


All times are GMT +1. The time now is 03:08 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.