Instance lists do not have to reflect the database that underpins them

Instance lists are conceptual.

They often reflect the physical structure of the database table(s) that underpins them, but they don't have to.

In this simple SECTIONS-EMPLOYEES relationship used through these examples, imagine the visual impact of a section containing 2000 employees. In a case like this you might consider inventing a 4 different child employee business objects named EMPLOYEES_A_G, EMPLOYEES_H_M, EMPLOYEES_N_T, EMPLOYEES_U_END to split up the children alphabetically into 4 groups.

Here's another simple example. Imagine you had a single database file containing messages. Each message has a unique identifying 7 digit number. Each message also has a status, somewhat like an e-mail, of RECEIVED, READ, SENT and DELETED. Conceptually this might be arranged into an instance list like this:

Conceptually the instance looks something like an e-mail inbox, outbox and deleted items. It is not directly reflective of the underpinning database design.