Hi BO Gurus,
My client wants to have Alias tables instead of using original tables in the universe and use the context for these Alias tables.
Can anyone please tell me is it good to do this way as I am assuming there will be many number of joins and contexts in the universe.
And is there any other way to do like this
Thanks in Advance
Madhuri
madhum1078 (BOB member since 2007-07-20)
By Aliases, do you mean synonyms to the original tables? The BO term for Alias really means re-using the same table in the universe design, but referencing it by another name. In that instance, you’re still using the original table.
digpen 
(BOB member since 2002-08-15)
Whenever I alias a table, I put the original to one side and create two aliases, giving them a meaningful name.
For example, if I had a table DIM_CARS and ran a rental and sales business, I would alias it twice, calling one A_DIM_CARS_RENTAL and the other A_DIM_CARS_SALE so that from the “A_” I’d know it was an aliased table and the RENTAL and SALE tell me in what way they are being used.
You don’t have to do this, but it makes it easier for you to see where aliases of tables are used, partly for impact analysis if this table changes.
I think the original poster is talking about aliasing every table, not just those that require aliases to resolve loops or solve other structure issues. Dennis Disney suggested that technique a long time ago in another topic. While there’s nothing wrong with the idea, I don’t remember what Dennis said the primary advantages were.
Dave Rathbun (BOB member since 2002-06-06)
I suppose one advantage is that if you have all the original tables “minimised” at the top of the schema, you can instantly see what tables already exist in the schema. Obviously there will be no performance advantages but it’s a reasonable approach to take when passing on universes for someone else to support/develop further. Might try it in my next place.
If you have a relatively simple universe, and the tables have meaningful names, then I see no reason to automatically alias every table. Create aliases as needed.
That said, in the great majority of universes I’ve created, I do alias all tables as a rule. A few thoughts as to why:[list]Makes the SQL more readable, because you can use more meaningful names.
In one (admittedly extraordinary) case, we used aliases to shorten the overall SQL statements. We were running into a 64k limit, and using 2 or 3 letter aliases solved that issue.
Consistency … if you use aliases for some, use them for all.
Layout / maintenance in the tables pane in Designer. By placing all of the original tables in a single “out of the way” location (usually far bottom or far right), it’s easier to see the complete list of tables used in a single glance.[/list]Some of these reasons are more valid than others … some are admittedly cosmetic … but there you go.
Dwayne Hoffpauir (BOB member since 2002-09-19)
Immediate advantages are size and time to refresh the structure. If a table exists 8 times (through aliases), you still only need to refresh the structure of the original table. I believe the aliases don’t take up much room in the universe either (not that the schema side without objects is exceedingly large to begin with).
My machine is still (STILL!) starting up, so I have a question for those that can test it. What happens if you copy/paste a set of tables with a pre-existing join. Does the whole thing get generically aliased?
If so, it would be a quick way to build join paths without creating contexts. You’d have to be very cognizant of what joins existed between the tables you officially made your objects from.
EDIT:
When you copy/paste groups of objects in the schema browser, it will prompt you to rename each table before applying them to your layout, and the joins will remain intact. By default a numeric count is appended to the end of the table name.
digpen (BOB member since 2002-08-15)