How to design an application to model a query with calculated fields

I'm creating an application to be a user interface for a database.

In this I have created Model's to replicate the database Tables. Everyone of my tables has an associated Model in my application

As an example, here is my TenureHistory table and its Model in my application which stores an employee start date and end date at a company.

class TenureHistoryModel
{
    public int TenureId { get; set; }           // tenure_id (PK)
    public EmployeeModel Employee { get; set; } // employee_id (FK)
    public CompanyModel Company { get; set; }   // company_id (FK)
    public string PaymentType { get; set; }     // payment_type
    public DateTime StartDate { get; set; }     // start_date
    public DateTime? EndDate { get; set; }      // end_date

    //methods omitted

Each property is a field in the DB table, the foreign keys are other models. This allows me to use any kind of SQL with joins all from the TenureModel class reading any attribute from those tables.

(I don't know if this kind of design has a name)

But sometimes I have SQL select queries that use calculated fields, for example:

-- MS Access SQL
SELECT 
  employee.employee_id,
  employee.firstname & " " & employee.surname AS full_name,
  start_date,
  end_date,
  IIf(IsNull([end_date]),Date(),[end_date])-[start_date]+1 AS days_length,
  (IIf(IsNull([end_date]),Date(),[end_date])-[start_date]+1)/365 AS years_length
FROM
  employee INNER JOIN tenure_history ON employee.employee_id = tenure_history.employee_id;

My question is, for queries like the above, in my application should I create another Model for the sole purpose of this one query used in my application.

Or, should I add the DaysLength and YearsLength as properties in my TenureHistoryModel (and FullName in EmployeeModel) that would only ever get used for this particular query.

Or, is there a different/better way