OWB general questions for effective use.

Question

Hi all,
I have been using OWB for a while now, and am getting to the point where I want to make sure I am using it effectively.
For example, how does one decide what to include in one project, or to split it up into multiple projects? I am loading a warehouse, and so far I am only loading raw data into tables.
My next step will be to perform ETL on the raw data and start forming more structured warehouse data. Would that step be better contained in a separate project? Would I need to repeat the definitions of the tables in the loading project? Should I just keep the whole thing in one project? The loading project is quite large, as we have raw data from many sources, and it seems to get one file in takes about 5 - 7 OWB objects (flat file, ext table, 2 - 3 mappings, process flow, 1 - 2 tables.)
So I have dozens of mappings, tables, etc.
Even though much of the data comes from different places, it is generally used together by the end users, and the ETL will likely also need to use most of it together.
Is there any "Best Practices" posted anywhere?
Another question that has come up is this: It seems the idea is to create the warehouse structures completely in OWB and deploy to the DB. However OWB doesn't allow for a full table definition, for things like Triggers, or for advanced features due to a later DB version.
So does one just create a "phantom" entry in OWB that is never deployed, and then create the actual table manually, or deploy and then modify manually to add the trigger?
Or are we not supposed to be using DB triggers, and instead control everything through OWB?
Any insight would be appreciated.
Thanks

Answer 1

Hi
I think the kind of questions you are asking are more aimed at methodology's not so much OWB. There are plenty of sites you can get this kind of info from one but not necessarily the best being <http://www.ittoolbox.com/>
In any case we use three projects and multiple schemas
project & schema 1 is used to collect data quickly from multiple sources
project & schema 2 normalizes the data (acts as the storage repository)
project & schema 3 is where the datamarts exist (de-normalized data)
this approach allows you to isolate your integration layer from your reporting layer. most changes only affect one of the layers, not all.
as far as creating your structures in owb is concerned I seen no problem, provided you are using a good ER tool and have ironed out any potential problems.
I have certainly created triggers manually and added them after deployment, but in most cases you can use Transformations, post-mapping, and pre-mapping processes to do the same thing, after all the data should only get into the target through a mapping. If it gets in any other way, you have a hole in you bucket.
Chris