Role Playing Dimension | Data Warehouse Concepts

In this video, we will talk about Role playing dimension.
Role playing dimensions are type of dimensions that are used multiple times with different meaning and purpose. They appear several times in the same fact table with unique labels.
Recommended structure in warehouse is to create independent views for each fact table foreign key and label all the columns in each of the views uniquely.
Please share your thoughts and feedback.
Thanks for watching.

[@AshokKumar-ji3cs]

Thanks for the detailed explanation. This is the best video I have seen till today

[@rickmemmer5625]

Informative, easy to follow, and elegant to boot -- very nicely done!! Thank you!

[@UmeAsh393-z4d]

Very helpful !! Easy to understand!

[@v-k883]

Jazz at the end sounds good.

[@ashoknidamanuri6361]

very nice explanation

[@jdisunil]

great eplaination.

[@jeanpierretueros7757]

thanks, and keep going!

[@indranisandur9644]

Great effort to explain topics simply. Thank you. One question, when we create multiple views for master table, will the views structure and data be same with just different names?

[@aroundBI]

Thanks for appreciation. Most of the time, for simplicity, we keep same structure. But it can be different based on requirement.

[@jeffharrison2840]

You mention foreign keys, but not the technical aspect of trying to build a fk constraint to a view. Do most solutions that use views for RPDs retain the foreign key nomenclature (e.g. ThisDate_FK) but not actually define it as a foreign key constraint?

[@junkingjunking8477]

What do you mean exactly by VIEWS? Please explain sir.

[@willbee6591]

Same question

[@huzischannel]

Cant we use single Date Dimension with left join for all the date fields in fact? Even when we create views on top of date Dimension we are essentially doing same thing.

[@shilpakr7963]

Tutorial is very helpful ..thank you ..can we not join the same dimension multiple times?

[@chrism3790]

The problem would be that when selecting from the joined table, all fields in the joined dimensions would be named the same. In this example, every date would be called "Date", so a more descriptive name would be helpful. I think that aliasing each column is a simpler solution, but you run into issues if people start aliasing the field differently in different places/datamarts.

[@jimmymemon]

My teacher with PhD in Computer Science from Harvard should be your student. No even kidding.

[@MuideenMuibi]

Great tutorial.. Short, precise and very easy to understand. However, I am thinking that what if I choose not to create views for the role-playing dimension, but rather decide to use aliases to separately reference the different roles of the dimension. Is there any problem with such approach?

[@jeffharrison2840]

Problems -- not necessarily. If that design meets your business's needs, it's the right solution. From all my research, there is a divergence on this point, but there is no argument that one option is absolutely the right option for every implementation. Views add some maintenance work, and don't allow for enforced FK constraints, but result in a very clean and orderly approach. Aliases add development work, but result in a more simple model. And your choice should fit with your BI tooling -- if you pick an option that doesn't work well with your BI tools, it's probably the "wrong" option.

[@AkshuGotuDance]

Thanks

[@karmagurung2098]

How can you reference a view in a foreign key?

[@jeffharrison2840]

From some other research, here are options: (1) you call your field "_FK" but you don't actually have a constraint on it; you rely on your ETL to enforce the "constraint" (2) you have a fk constraint to the physical table, but the field is named in such a way to point at the RPD/view. So the underlying table insures the constraint is observed, but the RPD is used for reporting.