Unless MOLAP is specified for a dimension, it will hit the underlying datasource at query time.
Member properties are being retired so just use attributes.
Its not a problem to have a very wide table and have loads of attributes - just dont use or hide the ones that you dont need.
Snowflake is now called 'Referenced dimension' in BIDS. Should be a rarity - situation like a product dim where there are a few diff types of product - all with wildly diff attributes that would leave a lot of NULLS in a single wide product table.
Fact/Degenerate dimensions - use an extra col in fact table to create a dim - avoid this as it will slow down processing and query performance.
Role playing dimensions are the same dim table used multiple times, called diff dim names, connected to fact table on diff col. Best example is different versions of a time dim - ship date/delivery date.
Dimension exist at the database level (when you design them) and cube level (mess with dim properties that are specific to a certain cube).
Many-to-Many dimension: maintains a bridge table from relational schema many to many relationship and then treats that bridge table as a fact table with the outerlying table as a dim table hanging off it. Bit like a snowflake but the mid table is treated as a nother fact. The designer wizard will pick it up correctly.
Visual Totals
Setting this for a role will ensure that totals dont show data for ALL data, even that the role shouldnt be seeing, instead summing on only allowed data.