To Name or Not To Name

[chet justice]

Semi-philosophical question.

In your presentation (or logical) layer, do you use "pretty" names or do you use the column names from the physical layer?

I tend towards giving them a "pretty" name in the presentation/logical layer so that it is easier to map from Answers.  I can then rely on "Display Related" to find the proper mappings.

I have seen an occasion where the Answers display name is derived via the Description box on the properties of the column in the presentation layer. 

Thoughts or experiences either way?

chet


chet justice

813.863.1213
http://oraclenerd.com
http://www.linkedin.com/in/chetjustice

[Jeff McQuigg]

Chet,

I will never recommend using database names for a user presentation
layer. That is fine for query generators like Brio where you are very
close to the physical structures, but not for a BI tool with a
powerful abstraction layer. To properly communicate meaning in an
analysis environment you need to put care into each name. I even
recommend a strong naming standards document be put together with the
customer so that fields are properly named with an aim to reduce
confusion.

Jeff M.

[Shyam Varan Nath]

We use say Erwin comments with descriptive names (or business meaningful names) to generate the data dictionary and then use these data dictionary names to rename the presentation columns. This helps the power users in adhoc reporting more than the canned reports (as canned reports the column headers can be easily renamed).

Thanks

To unsubscribe from this group, send email to obiee-enterprise-methodology+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[chet justice]

Thanks Jeff.

A naming standards document is a good idea, but my worry, as with any documentation, is that it will become stale relatively quickly.

How about creating an application (easily built by APEX say), that would contain the mappings and their proper (i.e. Business) names?  Something like this structure:

• DATABASE
• SCHEMA
• TABLE_NAME
• COLUMN_NAME (Database)
• LOGICAL_NAME (RPD, if different)
• PRESENTATION_NAME (RPD)
• PRESENTATION_DESCRIPTION

With that information you would have one (current, hopefully) source for the columns and their meanings which can be shared across subject areas.  Bonus points if you could apply that data somehow (I tried) to Answers for display purposes.

Currently, it is a mixture of both database names (complete with underscores) and "pretty" names with meaning to the Business users.  I'm more curious as to the best place to do this in the current release.  Is the "Description" box the best place?  I just don't want to have to migrate an RPD if the meaning of a column changes.

chet

[chet justice]

How do you rename the presentation columns?

[Alexander Hansal]

Hi Chet,

I agree with other respondents that the presentation layer should
never contain the physical names.

The presentation layer is simple yet powerful in allowing us to create
another two-dimensional layer of abstraction on top of the
multidimensional business layer. This is one of the main
differentiators of OBI EE and should not be spoiled.

However, what you might be looking for is the OBI EE metadata
dictionary which allows you to click an icon next to the presentation
layer definitions (in Answers) and see the data lineage down through
the business model to the physical layer.

http://obiee101.blogspot.com/2008/12/obiee-metadata-dictionary.html
(courtesy of John Minkjan).

Have a nice day

@lex

[Mark Rittman]

Chet,

My preference is to rename the business model and mapping layer names
(the middle pane), and let the presentation layer automatically take
up the names used in this layer. My rationale is that the "business
model and mapping layer" should by definition use business (i.e. not
RDBMS column) names so that it reflects the business view of the data,
the presentation layer then just automatically reflects this.

I do know others that keep the BMM layer names the same as the
physical table names, and then just rename the presentation layer ones
- Venkat for example does this when modeling Essbase sources, so that
the BMM layer names look like "Gen3,Product", "Gen4,Product" and its
only the presentation layer names that get changed do "Product
Category","Product Name" etc. But I prefer to use business names from
the BMM layer up, as I think this better reflects the purpose of this
layer upwards.

Mark

[Christian Berg]

For my part, technical names disappear as of the BMM layer. I support
Marks position here: the business layer is where the transition from
the technical to the business world happens..hence the name "Business
Model and Mapping" ;-)

One small side-note on Marks mentioning cubes though: if you have
multiple alternate hierarchies within one dimension and those are
(more often than not) unbalanced or ragged then these renaming
exercises can become interesting. I.e. how do you call your
Gen5,Organization logical cube column if that level contains the
country orgs for your sales org whereas it already contains the
employees for the HR rollup?
In this case you'll have to decide whether to make a hard split and
create multiple logical tables and dimension objects on the same cube
hierarchy object to be able to put correct naming tags on the
different dimensional levels or just work with the generic GenX
naming.

Cheers,
C.

[Mark Rittman]

On a related topic: I would be interested in hearing if people
automatically alias their physical tables, and then place joins, keys
etc on the aliases, or whether they just work directly with the
physical tables.

A bit of context: the BI Apps RPD features aliases for all of the
physical tables coming in from the OBAW, even if they are only used
once. For example, W_YEAR_D will get aliased to Dim_W_Year_D,
W_PAYROLL_A will get aliased to Fact_Agg_W_Payroll_A. This approach
could be considered good practice as

- there are lots of tables with abbreviated names, this makes it
easier to quickly understand their purpose
- it makes it clear what tables are facts and what are dimensions
(although the table suffix should provide this information)
- lots of the table have multiple roles, so needs to be aliased for
each of the roles

However I have seen people teaching OBIEE who automatically alias all
physical tables, even for the smallest source physical database, as
"best practice". Again, these aliases are then joined, have PKs and
FKs assigned, and the BMM is then built off of this. Possible reasons
for doing this are:

- It's the Oracle standard
- It provides a degree of abstraction away from the source tables in
case their definition or name changes
- it looks neater and makes the purpose of the tables more apparent

However it also adds another layer of complication to the RPD, makes
the development process take longer, and is another thing that can go
wrong.

So - does anyone have any preference on whether physical tables should
ALWAYS be aliased before adding keys, joining and mapping to the BMM
layer?

Mark

On Mar 22, 4:52 pm, chet justice <chet.just...@gmail.com> wrote:

[je...@brewpalace.com]

Hey Mark,

I am a firm believer in aliasing every table all of the time, and have been doing so long before the BI Apps started to do it.  In combination with a naming standard, I believe it is a developer tool to help cut down on errors (such as circular joins) and helps you to manage/organize your RPD better. 

However I differ with Oracle's naming standard, which is too physically oriented.  I prefer one that indicates the reason the alias exists, and that reason is called its logical usage.  Thus, I always recommend the following:  Logical Usage (PHYSICAL_NAME).  For example, Open Date (W_DAY_D). 

Doing it like this allows you to see all of the other tables you may have for a given logical table together as opposed to being spread out everywhere. 
Open Date (W_DAY_D). 
Open Date (W_MONTH_D)
Open Date (W_WEEK_D)

This fits in perfectly with the Top-down approach, where the physical is there to serve the logical layer.

With OBI, aliases are always in synch; keeping each alias of the same base table therefore provides little benefit.  (This was more important with Siebel Analytics which did aliases differently and synch issues were common)  Is there benefit to Oracle's way?  Yes, but I don't think as much with doing it the way I showed above.

As far as the downsides go, I don't think they are as bad as you suggest. Aliasing is pretty simple stuff.  In many case's you'll be doing it anyway, so then you would be inconsistently applying your aliases.  Besides, what if at first you don't use one but then later you need to use one?  That is not worth the re-dev pain.  I think the risk of additional re-development far outweighs the minimal aliasing effort.  And as I mentioned before, I think it cuts down on your errors, not increases them.

Jeff M.

---

From: Mark Rittman <mark.r...@rittmanmead.com>
To: OBIEE Enterprise Methodology Group <obiee-enterpri...@googlegroups.com>
Sent: Tue, March 23, 2010 11:38:58 AM
Subject: [OBIEE EMG] Re: To Name or Not To Name

[Christian Berg]

> if people automatically alias their physical tables

Oh yes! It's basically one of the ten commandments of RPD design...actually that's not correct since they're not all that universal. It's basically like taxes: Do it or be punished.

> So - does anyone have any preference on whether physical tables should
> ALWAYS be aliased before adding keys, joining and mapping to the BMM
> layer?

Personally I say: yes, always. It's not hard or hugely complex and while it adds some additional objects to the physical layer there's always the question: are you 100% sure that the model won't be extended/re-used? Hence forcing you to go in and alias the whole thing, then adjust the existing business model and then do the actual changes you wanted?

Doing it right from the start, for me, is the way to go. You keep the amount of modifications necessary to accommodate change limited and reduce the potential for introducing errors into something that's working. No one knows who will do the next change or whether the original developer will still be around...with a clear and common guideline and way of doing things you eliminate quite some issues right from the start.

As far as naming goes I'm with Jeff. That's the form I prefer to use simply because it provides a clear logical context. It's also educational for developers thinking too much on the tecchie side of things.

Cheers,
C.

[Mark Rittman]

Christian, Jeff

You've convinced me, they were well argued points.

Once these threads have died down, I'll summarize some of the modeling
points in a Word doc that I'll upload to the OBIEE EMG documents area.

this is the kind of debate we were hoping for when we put the board
together, thanks everyone.

Mark

> <mark.ritt...@rittmanmead.com>wrote:

[stijngabriels]

One thing which isn't mentioned yet, is that the alias name of a table
is referenced in the SQL generated by the BI Server. This makes the
SQL better readable and more understandable, also for other
developers.

Stijn