do you need to maintain a record of employee change of address?
do all employees in the same position get the same rate, regardless of dept?
You could arguably merge the dependents and employees table and just call it a persons table and then create a further table called PersonJunction.
This table would hold the links between individuals.
Such a table should include at a minimum
PrimaryKey (autonumber)
FKIDPerson-Guardian
FKIDPerson-Dependent
You will see that you are repeating the structure of the employees in the dependents table. Merging them and then creating a junction table is a stricter application of the rules of normalization and is preferable if an individual can be both a dependent and an employee. This is possibly an edge case for you but it can facilitate the creation of lookups for a field where the value should be chosen from either dependents or employees.
many to many relationship?
dependents+employees = persons
personJunction
one to many?
persons and personJunction
in that case your tables and relationships need more work. since its current structure will not support that requirement. Your project is starting to suffer from 'mission creep' in that you have not fully defined all the requirements. Suggest you sit down and clarify them in fullsome department has the same rate per position while other has different rate.
jmq,
Have you completed your earlier project? Or just extending your Normalization learning?
As others have said, getting a clear description of what is required is a key first step. As CJ pointed out, "mission creep" is a red flag --- look to your requirements and verify the scope of your project.
when you say junction you mean a many to many relationship
so if I merge the dependents+employees = persons then create a junction labelled personJunction I think this will result to
one to many? cause I only have 2 tables now persons and personJunction
If you submit a db here, include a description of the business the db is intended to support.
You need to be able to compare the data model/ database structure (tables and relationships) to the business facts identified in the description of the business.
Sounds like you're learning -- making a few models and working through them and adjusting as needed is great experience. Much like sailing --you can read books and theory, but at some point you have to get out on the water and get wet.
underscore and then a number eg _1. This is NOT a second copy this is the same table. You now have three objects with which to create your 2 one to many relationships.
Here's a link to the kind of relationship you should then set up.
http://rounduptheusualsuspects.org/wp-content/uploads/2017/11/ManytoManyRelationships.png