Mapping Content Best Practice

Question

Anyone got suggestions on best practice for mapping contents...
a) create a lot of mappings - almost 1 for each table, dim, etc;
b) put many items into logically grouped mappings (e.g. staging static data extract, staging fact extract, etc)
c) somewhere in between - most staging stuff gets chucked together, major dimension/fact refresh has its own mapping, possibly put many related smaller dims (status, etc) in one mapping, etc..
I assume the considerations are parallel execution, monitoring, maintenance/clarity, simplifying process flows, etc.
I suppose I'd go for c), but if anyone can suggest things to avoid that'd be good!

Answer 1

Hi Chewy,
Mapping composition is not an exact science, as you state yourself.
The problem also extends to workflows and workflow subprocess division.
I've made some core rules for myself, that may work for others too:
1) If I want to be able to reload a target in case of problems, it should be in a separate mapping.
2) Generally, each target file has its own mapping. If several disconnected flows have the same target, I put them in the same mapping.
3) If I split a single source into multiple targets, I generally use a single mapping for that
4) If flows are complex (have many operators), I never put two or more together. If your 3600x4800px monitor can't display all of your mapping, you're on wrong track.
5) If I want to sequence simple flows and don't care about 1) or which one runs first (10gR1 caveat), I put them into the same mapping. Eg. when the source cannot handle concurrent queries well.
When it comes to workflows, things get more complicated.
In my current project, most source data moves through three modules: staging, ods (relational), and data mart (star schema). I have two requirements for packaging mappings into workflow subprocesses:
1) There should be a subprocess per source module that transfers all data from the source to the staging area
2) Each target (dim or cube) in the data mart should have a silo-type subprocess that handles the data from staging through ods into the data mart. Rule 1) from mappings applies here, as well.
To do this efficiently, you should have a PL/SQL function that checks eg. if the source loaded successfully into staging before commencing with target loading.
Regards, Hans Henrik