can anyone help how do i make this table and relationships??

[Guest]

Below is the warranty particulars of a software inventory database, i'm
having problem in making tables and their relationships. so can somebody help
me out or give me any tips please. i'll be very thankful to u.

WARRANTY PARTICULARS
* Number of Years (Parts)
-Part
-Type (On Site?)
-Replacement (Y/N)
-Starting Date
-Expiry Date
* Number of Years (Labour)
-Type (On Site?)
-Starting Date
-Expiry Date
*Transportation
-Vendor's Responsibility
-JWT's Responsibility
*
-Backup Commitment (Y/N)
-Backup Level
--Same Configuration
--Lesser Configuration (Acceptable)
-Insurance Policy Reference
-Insurance Policy Expires on

 

[Avlan]

I'm afraid this is something you have to do yourself :-/ We can't
estimate how your data works and all.

When you make tables, try to make every table as basic as possible.
Usually this means you have to identify which parameters have
one-to-one or one-to-may-relationships. If parameters have one-to-one
relationships, you can put them in the same table in different colums.

For instance, say you would make a table with contacts names and
addresses, you could put them in one table with colums 'name',
'address', 'telephone number' because only one contact lives at that
address and uses that phonenumber. It's no use putting all phonenumbers
in a different table and linking them one on one to the 'base'-table.

If, however, you would make a table with employees names and their
office addresses, you might wanna split of the office addresses into
another table if certain addresses are used multiple times. If, say,
you have 200 employess who work at 13 different office addresses, you
would probably be smart to put those addresses into another table (with
13 rows, columns: 'address','unique identifier') and link the addresses
through the unique identifier (table with 200 rows, colums:
'name','AddressID' where 'AddressID is linked to 'unique identifier' in
the other table').

An advantage to the last one will be clear when say 36 employees work
at an office say in Amsterdam, but at one point the office will move to
Rotterdam: If you would have put users and offices in one table you
would have to edit all 36 rows to change the address of the office. If,
however, you would have the addresses in a seperated table, you would
only have to change the address from the Amsterdam office; the unique
identifier will remain the same and all the 36 users will still be
linked to the office, but now in Rotterdam.

In you database, it would be smart to first try to find out which
properties are unique and can be placed in one table without too many
double entries. If you make your table and you have to type the same
description for the fourth time, you might want to check if you can
split of that column into a seperate table.

It will probably take you some time to really get to the bottom of how
to split up your tables, but take your time because it will surely save
you lots of time later.