The difference is in the modelling of your entities. You could just as easily break the one entity into two entities and have a relationship between them, but here are some questions that
you should pose to your object model (EMPLOYEE/EMPLOYEE_AGE in your case) to influence you one way or the other:
- Are they always operated on together or do you have a reason to encapsulate them separately as to objects?
- Does the second entity (EMPLOYEE_AGE) have its own identity? Will it ever be created independently from the EMPLOYEE, or are they alrways created/deleted together?
- Is there ever any need to query against the EMPLOYEE_AGE without going through the EMPLOYEE?
- Do you ever want to not load EMPLOYEE_AGE, i.e. if you had a relationship are there times when you would want to lazily load it?
The answers to these and other entity modeling questions would determine whether you should make them one entity or two (or possibly even an embedded object).