Please could you experts assist me on normalizing my tbl structure below-

Employee_EmployeeID
CompanyName
Employee_FirstName
Employee_Surname
Employee_Sex
Employee_DOB
Employee_Coverage
Address
City
County
PostCode
StartDate
LeaveDate
Employee_Health
Employee_Dental
Employee_Travel
Spouse / Partner_FirstName
Spouse / Partner_Surname
Spouse / Partner_Sex
Spouse / Partner_DOB
Spouse / Partner_Coverage
Spouse / Partner_Health
Spouse / Partner_Dental
Spouse / Partner_Travel
Child 1_FirstName
Child 1_Surname
Child 1_Sex
Child 1_DOB
Child 1_Coverage
Child 1_Health
Child 1_Dental
Child 1_Travel
Child 2_FirstName
Child 2_Surname
Child 2_Sex
Child 2_DOB
Child 2_Coverage
Child 2_Health
Child 2_Dental
Child 2_Travel
Child 3_FirstName
Child 3_Surname
Child 3_Sex
Child 3_DOB
Child 3_Coverage
Child 3_Health
Child 3_Dental
Child 3_Travel
Child 4_FirstName
Child 4_Surname
Child 4_Sex
Child 4_DOB
Child4_Coverage
Child 4_Health
Child 4_Dental
Child 4_Travel
Child 5_FirstName
Child 5_Surname
Child 5_Sex
Child 5_DOB
Child 5_Coverage
Child 5_Health
Child 5_Dental
Child 5_Travel
Child 6_FirstName
Child 6_Surname
Child 6_Sex
Child 6_DOB
Child 6_Coverage
Child 6_Health
Child 6_Dental
Child 6_Travel
Notes
DateUpdated


Hope you can help me!
Ta
Kasey

At a basic level I'd suggest:

1) employee table
1a) The company name might benefit from a separate table, if they all belong to the same company is this field even necessary?
2) Spouse Table
3) Child Table
4) Junction table between Employee and Child

You can make further arguments that at least elements of the address could be split out to a separate table (such as Town/County)

Without knowing what is in the dental/coverage/health/travel columns it's difficult to suggest any potential improvements around those areas. If they are simple Y/N flags then they're probably ok, if travel might contain "Mileage" "bus pass" "rail card" as potential values then a TravelType table that can be linked to Employee, Spouse and Child might be in order.

Here's a good starting place:

http://r937.com/relational.html (Relational Design)

You need to recognize that child 1, child 2, spouse, are all PERSONS. So, for that matter, is the employee.

I see one table for ALL persons.

tblPerson
PersID, autonumber, Prime Key
Name info: FName, MName, LName, NamePrefix, NameSuffix
Coverage Info: Health, Dental (Codes or Y/N?)
DOB, gender, other personal data
ResID - Foreign Key (FK) to residence table (below)
Don't understand "Travel" but if it is a per-person thing it belongs here.

Persons have to live somewhere, so

tblResidence
ResID - autonumber, PK
Address info: Street number, street name, apt. designator, city, maybe county, state, postal code
Telephone info

A wrinkle would occur if you tracked multiple phones for each person such as home phone, cell phone, office phone... which would warrant a table of phone numbers and a junction table of who could be reached at which numbers.

Then other tables:

tblEmployer
CompID - possibly autonumber, PK
CompanyName, other info

tblEmployee
EmplID - employee number for the company, which might not be all numeric and even if so, might not be autonumber
BossID - identifies the employer
PersID - identifies the person who is the employee, foreign key to tblPerson
Other info that relates specifically to the employment

tblRelations
PersID1 - FK to tblPersons, left side of relationship
PersID2 - FK to tblPersons, right side of relationship
RelType - perhaps a code that defines relationships
e.g. {PersID1} "IS" {RelType} "OF" {PersID2}
so you could have codes for Spouse, Child, Parent, Live-in Lover, Love Slave, whatever relationships you track... (Just wanted to see if you were still reading.)

Employment appears in your tables to be relationship between multiple employers (else why would it have appeared in your list) and multiple employees - so you describe employment via a junction table to support the many//many nature of that relationship.

Familial relations are also many//many, so another junction table is needed. The only catch is that both junctions are to the same table.

Sometimes normalization gets ugly. But then, if you wanted the perfectly general case, that is AUTOMATICALLY ugly anyway, so the model is good.