A parent storage group is one which contains one or more storage groups(children) that contain devices. The parent child relationships is useful for a variety of reasons such as more granular snapshot and restore capabilities, multi-tennant use cases where you have multiple applications presented to virtual clusters, and simply for better organisation of devices. There is more information on this in the solutions enabler array controls guide.
One example, from the Oracle space, is to create a child SG (storage group) for the Oracle data files (e.g. data_sg) and another for the redo logs (e.g. redo_sg). Aggregate them under a parent SG (e.g. database_sg). Then use the parent for operations that relate to the whole database:
1. Masking view.
2. Remote replications with SRDF (create a consistency group that includes both data and logs).
3. Local database snapshots using SnapVX (a snapshot containing both data and log is considered 'restartable' and you can use it to instantiate new copies of the database, or as a 'savepoint' before patch update or for any other reason).
However, if you need to recover production database, you only want to restore data_sg and not redo_sg (in case the online redo logs survived, as they contain the latest transactions). Therefore, although the snapshots are made with the parent (database_sg), you can restore just the child (data_sg), and proceed with database recovery - all the way to the current redo logs.
Another advantage is separate performance monitoring of the database data files and logs. When using the child SG's you can monitor them separately for performance KPIs without the redo logs metrics mix up with the data files.
Finally, with the introduction of Service Levels (SL's) back into the code, you can use them differently on the child SG's if you so wanted (e.g. Silver for data_sg, gold for redo_sg, etc.)