Sql-server – How to change the SSAS Multidimensional Cube partition location on disk

Parent-child relationship in SSAS isn't straight forward as we might wish. From my experience in SSAS 2008 linking them both together wasn't simple at all. In those type of cases the most recommended solution would be to flatten the relationship with a (SQL) view in which you link the parent to the child with the date attribute. That view becomes your dimension and on which you check the changes over time. you can find more data about this in here:
http://www.kimballgroup.com/2007/10/design-tip-95-patterns-to-avoid-when-modeling-headerline-item-transactions/
and here:
http://www.kimballgroup.com/2012/05/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/
Alternatively: If you need both the Parent id and the Child in the fact table (because you need to query on both) then in that case I would go on a different direction and include both id's in my fact table. This way you can monitor changes across time as you would for any other dimension.

I would recommend you start by reading this excellent introduction to SSAS processing.

To answer your questions:

1. You should ProcessUpdate your Date dimension then ProcessIndexes your cube. ProcessUpdate will not unprocess (unload) your measure group partitions like ProcessFull which is important if you only want to process the latest year partition. But it is a best practice to ProcessIndexes at the end of the transaction to rebuild the flexible aggregations and indexes that were dropped when dimension rollups changed during ProcessUpdate.

2. Yes if the Postal Code dimension changes only yearly you can omit it from your daily processing scripts.

3. For the measure groups with just one partition, processing the partition has the same effect as processing the measure group. I would recommend a ProcessData on measure groups or partitions that need reprocessing then a ProcessIndexes on the cube.

By the way beware of the Analysis Services processing task in SSIS. When you set it up the database ID is hardcoded in the command it builds and editing the connection string of the SSAS connection manager to point at a different SSAS database name won't change which database it processes. So that SSIS task only works well if you are sure you will be processing the same database ID on each server and won't ever need to process a second SSAS database on the same server.