hi
can anyone tell me when will we use metadata exchange and table mapping in designer?
thank you
judia
judia (BOB member since 2008-06-24)
Judia,
By metadata exchange and table mapping are you referring to the ability of using Designer, pointing it at a database, pressing a button, voila, your tables and columns are imported, all joins are connected, and objects suddenly appear in your left-hand pane? Or, are you also talking about developing a BI solution using vendor X and one day you wake up, go to work and decide to use vendor Y, so you grab a copy of vendor X’s meta data and make it resident in vendor Y’s meta data repository, go get a cup of coffee while the workforce begins generating their own reports in vendor Y’s enviornment? If yes to either of these scenarios, then the answer is it depends. You see, in the dark ages before SQL we had COBOL, FORTRAN, ADA, Clipper, etc, etc, and none of these databases talked the same syntax (or language). Then we had ANSI SQL, then ANSI SQL-92, and life has somewhat gotten better, but we’re not there yet. IMHO, the meta data exchange will only come about when enough vendors see the value of it, but not before. I work in a relatively moderately size operation (2 GB of data warehouse, 600 users, etc, etc), and it took a two-person team here a year to switch vendors (this included supporting the current users, attending vendor training, re-doing the meta data (universes), rebuilding the reports, and user re-education). So what vendor wants me to be able to up and run from X to Y on the fly? If the meta data was exchangable I could do it in a month’s time, but otherwise it could take a year… Hopefully these notes here do make sense to you and have shed more light to your question.
Thanks,
John
jsanzone 
(BOB member since 2006-09-12)
Whether or not you need table mapping depends on your requirements and what you have at hand.
I can give you an example in our environment with our legacy financial data. At that time, we had three kinds of users.
1.) Able to see all data, no restrictions.
2.) Able to see all data except for funds which were set up as Living Trusts
3.) Able to see data only for a particular branch of the organization tree.
We set up three different views for this data, with the latter two having row-level restrictions imposed in the view – and granted the appropriate view to each user group (our users have individual logins into the database).
Then, in our universe, we built the core universe on one of the views (#2 as it turned out) – and included the other two views elsewhere in the universe, not used directly in objects, not joined into the data model.
Then, in Supervisor (since we’re still pre-XI), we used Table Mapping for groups #1 and #3 to “swap” the fact table-view in place of table-view #2.
Anita Craig (BOB member since 2002-06-17)
thank you john ad Anitha.
judia
judia (BOB member since 2008-06-24)