Using detect context

[Former Member]

hi All

Currently i'm working on the universe design with teradata as back end. I worked on the model and solved the loops some with aliases and contexts. I tried using 'detect contexts' for solving some loops but it does not work properly. I included all the joins and cardinalities as in the Physical data model and aliased the tables where it was decided to use them. We do not have any reporting requirements yet to define the contexts properly

My questions is Does detect context work all time and do any one have any experience of using with 3NF as back end?

any help would be very much appreciated.

thanks and regards

hk

[Former Member]

hi all

thanks for replying

I manually set the cardinalities according to the PDM i was given and then did the auto context.

I'm sorry but i should have provided more information on the issue. When i did the auto context it detects many contexts and some contexts are applied for only one join and or/ a couple of joins and none of these joins are part of the loops in the universe.

I hope i made my issue clear.

Edited by: harakrishna on Nov 19, 2010 3:41 PM

[Former Member]

It may be the case that only one join is relevant in a particular context. Once you create a context, all joins in the universe must belong to at least one context.

I would suspect that you may have 1 to 1 or self-restricting joins in your universe.

[Former Member]

Yes we do have one-one joins in the universe. Also the other contexts created wouldnt suffice the requirements of the clients for reporting (as much we know of) even though the loops have been solved. so i'm considering doing it manually. Though the client is still set on using the auto detect option as the reporting requirements are not much clear and specific.

[Former Member]

The reporting requirements are irrelevant for contexts compared to the database cardinalities.

To fully use detect contexts, you need to understand which end of the one-one joins need to be changed to many and that's it.

[Former Member]

I will offer a different viewpoint than Noman.

While the detect contexts is not 100% correct, it is still a useful tool. You have to set your cardinalities correctly in your universe because that's how it identifies chasm traps and loops. Even at that, it can make mistakes. But it's not useless.

If you can provide more information about how it failed for you, I can provide more specific advice. But saying "but it does not work properly" does not give us much to go on.

[Former Member]

Dave,

Thanks a lot for your thoughts and I agree giving a blanket statement like "it does not work properly" does not give us much to play around with

From my experience, I have seen that the "Detect Context" feature works pretty well for a dimensional model. The problem arises when you have a normalized model, sometimes with 100s of tables which I believe was the case mentioned by the gentleman above. I say this because of a couple of reasons. Firstly, I have seen most people setting-up the cardinalities through the tool and not by themselves. I tend to set them myself since a lot of times when you start developing your sementic layer you do not have true representative data in the tables - some lookup tables tend to have more values than the fact table! Now when the Designer fires of a couple of select statements to get the row count and decide cardinality there is a good chance that it will get it wrong.

Secondly and most importantly, from my experience if the developer understand the model and the business logic, setting-up contexts manually gives them a higher level of confidence. I have worked with universes that are based on 3NF models (which often is the case if you are building on a Teradata LDM) and I agree it can be a real challenge setting all the contexts manually but at the end of the day it gives me not only ture understanding of the entire layer but makes my work even easier when in future new tables are added in the model and I can quickly figure out which context will it go in or if I need to create a new one.

- Noman Jaffery

[Former Member]

I must agree with Dave here.

Setting up the cardinalities correctly is key to the context detection algorithm.

What is important to note, though, is that one-to-one joins and self-restricting joins don't fit with the algorithm. What the algorithm does is find tables that only have "many" ends of joins connected to them. In a dimensional model, these are typically your fact tables. The algorithm then chases out these joins, adding them to the candidate context list and keeps going along the many ends.

For example:

A -< B >- C >- D -< E >- F

B and E are fact tables. The algorithm would identify B and E as base tables for the candidate contexts.

The context based from B would find the joins A-B, B-C and C-D then see that D-E is one to many, not many to one, so would stop there. The context based from E would contain D-E and E-F, stopping at D-C for the same reason as above.

As long as you understand the rules, you can always apply them. I often set one-one joins as one to many for the purpose of context detection, but this obviously relies on an understanding of the data model.

You also hinted on cardinality detection. That is probably the most pointless tool in the box, especially if you've been given the data schema already. I always set cardinalities manually.

[MariannevL]

Hi Norman,

I'm sorry but I also do not agree with you. And I have some experience building universes too, also on 3NF models.

From my experience it is best to look behind the model and work to logical contexts,

much like when you would define a data warehouse for this data.

I do this by creating the aliases, derived tables and setting the cardinalities right.

When the detect context does not result in the what I had in mind, I go to debugging mode and check why it reports it the way it does. This might be a simple mistake and I typed the cardinality wrong.

But it could also be that it is right. Then I choose a solution for the problem detected.

A problem that I might not have seen if I hadn't used detect contexts.

Either way, when you have a real chasm trap and you put it manually into one context,

a user can get back wrong results.

So I'd say yes, always use both methods available to you;

your own mind (into thinking about the contexts),

but also use the power that detect contexts brings to you (especially in the bigger schema's

Good luck,

Marianne

[Former Member]

I would strongly suggest you not to use "Detect Context" feature specially if your model is based on a 3NF structure. At the end of the day the tool does not have understanding of the business understanding on which these contexts are created.

If you are using Teradata and one of their LDMs then the only way to go about it is to do it manually. It is get very complicated but that is the only way around.

- Noman Jaffery

[Former Member]

thanks for your reply Noman.