Do I need one more simple class for searching a complex business entity?

Question

One intelligent business object may actually containing information from multiple database tables. Constructing the business object may require multiple database queries. However, sometimes you don't need the full information of the business object. Do I need to create one more simple class just containing the basic information of the business entity?

I have an example of Department:

public class Department {
    String name;
    String description;
    //have to query other Table to get headOfDepartment
    Employee headOfDepartment;
    //have to query other table to get members
    List<Employee> members;
    //have to query other table to get subDepartments.
    List<Department> subDepartments;
}

To construct "Department" object, I have to make multiple queries to different database tables to get the members, headOfDepartment and subDepartments.

If I just want to list all the Departments, actually I don't need "members", "headOfDepartment" and "subDepartments". All I need is "name" and "description" for each "Department".

In this case, I have two solution:

1) Creating a class named SimpleDepartment like:

public class SimpleDepartment {
    String name;
    String description;
}

2) Using Department, but don't provide the full information. In this way, a "Department" object may containing following data:

Department{
name:"CCS"
description : "CCS is under CEO office to help CEO handling emails."
headOfDepartment : null
members : null
subDepartments : null
}

Which solution should I choose?

Answer 1

Since members can belong to one department only. And subdepartments can also belong to one department only - you have one-to-many relationships here.

It's common to store list of keys of these entities. And if needed fetch these entities by their IDs. This approach is commonly used for Big Tables for example in Google Appengine entities.

So I would suggest having 1 entity which stores keys for members and subdepartments.

public class Department {
    String name;
    String description;
    //have to query other Table to get headOfDepartment
    Employee headOfDepartment;
    //have to query other table to get members
    List<Employee_Ids> members;
    //have to query other table to get subDepartments.
    List<Department_Ids> subDepartments;
}

Answer 2

Well, when I face this issue I use to take diferent aproaches according to the common use of the classes. If the most common use on my application is going to be the simplest definition class , then I divide my class in two and I extend the most complex from the simplest. If the use of the simplest isn't going to be so common, then I just use the complex one and inicialice as null the unused properties. I do that to keep my code as clean as possible.

public class Department {
   String name;
   String description;    
}
public class DepartmentComplex extends Department{
   //have to query other Table to get headOfDepartment
   Employee headOfDepartment;
   //have to query other table to get members
   List<Employee> members;
   //have to query other table to get subDepartments.
   List<Department> subDepartments;
}

If the use of the simplest isn't going to be so common, then I just use the complex one and inicialice as null the unsued properties. To keep two null properties in a class isn't going to rob you too much memory.