If Table-A is in a Master-Detail Rel'n with Table-B then the details in Table-B ought to be visible as a set of details under a summary of Table-A data if there is a Common reference point in Table-A. Like a common DATE in a Calendar shared with a number of records in Table-B that may or may not share a common time reference from Table-B.
Ie: 12 records in Table-A share the same DATE which is the common value linking them all in Table-B. In Table-B the Times are all broken down to be displayed in a familiar format for users. This could be the set as a VIEW in Table-B that then becomes the DETAIL records displayed when the Calendar DATE is clicked rather than being limited to just the views in the Master Table-A.
I have several places where the ability to display related details from a Master-Detail relationship as the details page behind a summary (a Calendar for instance since this is my current hang-up) would be very handy.
While the Details of such a relationship can be displayed below a specific record, the current arrangement does not allow for a similar detail of records from a 2nd table that share common data to be displayed as the details of a summary.
In the case of a scheduling calendar we use, I have a 2nd table which holds the data in 15min intervals for scheduling which then is accessed in a summary rel'n just to get it back into the Master Record table so it can be displayed in a calendar format and, via VALIDATIONS and other measures, prevents users from creating a scheduling overlap. It works but this would be SOOOOOOOOO much simpler to display and make work, and far more familiar to users if , when they click the date to view details, the underlying DETAILS table could simply be a VIEW from the 2nd table. And wouldn't it be even better if the drag-and-drop functions worked in that VIEW TABLE environment so a user could click on a record and drag it to a new available time slot?
A calendar is just one example where I have a use for something similar, the best use example perhaps but not the only one.