About levels in dimensions

When creating a cube I can choose the level of the dimension when creating the foreign keys. Why does OWB support other than the lowest level? I tried to use another one (month instead of day) but I got an error when validating. So I have to create another dimension with lowest level month?
Regards,
Torsten

Unfortunately, this is currently not supported in OWB.
Regards:
Igor

Similar Messages

Problem in Aggregate with Multiple level of dimension

Hi,
I have a BI repository with a snowflake schema. I have also designed the business model with snowflake, It works with drilling and all but I am facing problem when I am
creating a logical column aggregating with a higher level of dimentation. Let me illustrate that :
I have the Following Hierarchy :
Tournament(id, Name) ---- > Round (id, name, tournament_id) -------> Match (id, Name, RoundId ) | Match is fact table and other 2 dimension.
I also created a logical dimension called tournament with 3 levels.
Now say I want to create a logical column Total Number of Matches , aggregating to the dimension level of Tournament. The result gives counts a 0 for every tournament. However
it is working perfectly when the dimension level is Round (which is the immediate next level after fact).
The Logical request generated (in case of Tournament level) :
   MatchId:[DAggr(Measure1.MATCHID by [ Matches$.TournamentId] SB Tournament)] as c1 GB.
    There is no such column as TournamentId in Matches$ table. How does the BI server got this ?
   The execution plan evaluate this:
     cast(NULL as INTEGER ) as c1 GB [for database 0:0,1]
   Can someone please explain why is this happening, is it because of the snowflake schema, but I guess if BI server can handle a snowflake schema it should work the Aggregate
   properly in multiple levels of dimensions, or it is something I am doing wrong.
   Execution Environment:
     Windows XP , OBI 10g on OC4J. Data source : MS Excel (ODBC 3.5)
Regards,
Ru

Hi,
With reference to your question.
Can any operator perform this task..I don't think any single operator will help you.
I suggest using an intermediate (staging) table by using a PL SQL procedure with output port to store the values of account number provided the number of accounts are limited. Else use an array variable for account of an employee.
In short no simple solution because of the bad source design else the pivot/unpivot operator would have helped you.
Cheers
- Mohammed

Lowest Level in Dimension

HI guys
i have rdbms 9.0.4
can i define lowest level of dimension that is not the primary key of the dim table ( this field has unique values)
or the lowest level of dimension should be the primary key of the dimension table.
thanks alot.
Brad

Hi Matt!
Glad to read you again!
I agree with you that in this simple example, I should be able to make this a star schema.
but :
- on a functional point of view, this date is an attribute of a vehicle, not of an invoice. But let's ignore this.
- this problem is the same as one we have in another part of the BM, which is much more complex. In this complex BM, I can't use star schemas because it removes some joins we need in order to perform some reports.
This is why I'm looking for another way to proceed.
If you have time to spend on the complex BM, here is a simplified description :
* in the physical layer, I have:
- a calendar table with multiple aliases to be used with each dates in the following,
- an invoice header table
- an invoice detail table
with
some header date -> header table -> detail table
some detail table -> detail table
* in the logical layer (stars), i have:
- my calendar dates with their dimensions
- an invoice dimension table with the two sources (header + detail) + its dimension
- an invoice header fact table
- an invoice detail fact table
header date -> header fact
invoice dim -> header facts
invoice dim -> detail facts
detail date -> detail facts
I mus be able to query details facts while showing or filtering the header date. In such a configuration, you'll understand it isn't possible as there isn't any relationship between the detail facts and the header date. This is why the header date should be kept as a dimension of the invoice dimension, which is similar to my basic example.
Unless I went wrong somewhere?
Thanks!
Ced.
Message was edited by:
ced

Populating cube on any level other than last level of dimension

I have an employee cube with three dimension in warehouse builder. i have a measure to count employees in this hierarchy division > department > sub_department. i have to sum salaries also but data is available up to division > department.
how can i do it in the same cube using same dimension while cube mapping provide me the last level of dimension sub_dept_code. can i populate at department level instead of sub_department for this measure only while not effecting other measures data.
thanks
muhammadimran

Muhammadimran,
I don't think you'll be able to do this. The FK relationships between the fact table object and dimension table objects (regardless of the dimension and cube representations) will join only to the lowest level. I'm not sure I quite understood your post - is it that you don't have data at the lowest (sub-dept) level, or that you want to be able to see the sub-department data, but also summarize it up to the department and division levels?
Assuming you mean the latter (i.e. you want to see subdepartment data, but also summarize it to department and division levels), you simply use a sum() in the SQL. Any and every BI tool you'd put on top of this will do that.
If this is more of a performance issue - i.e. it takes 20 minutes for data to come back at the summarized levels...then take a look at creating materialized views and using query rewrite. All in all, you don't want to try to store facts at different levels in the same fact table (although OWB was obviously set up to allow this....it doesn't work well in practice).
Hope this helps,
Scott

Displaying non-level determining dimension attributes in bibeans with cwm2

In the bibdemo example (defined using the CWM API), the attributes PROD_COLOR and PROD_SIZE are defined as dimension attributes of the Product dimension. They are then available to bibeans applications for use in the query editor/match condition (as where clauses e.g. where Size = LARGE).
When I define OLAP metadata objects using the CWM2 API, my non-level determining dimension attributes are not available in the bibeans query editor.
Has any one exprienced this problem? Is there a work-around or code fragment that explains how to get dimension attributes defined using CWM2 to work in bibeans apps.

basically there are list and hierarchical dimensions.
the first type doesnt have a hierarchy, so some sort of special case of the 2nd.
i used attributes on list dimensions successfully in the past.
the only thing i had to do is nevertheless define a "artificial" level.
let me know if you need more,
thomas

Drill down is not working in 3rd level of dimension hirarchy

Hi,
drill down is not working in 3rd level of dimension hirarchy,any issues. once i clicked on 3rd level it goes to detail level instead of going to 2nd level
thanks

any updates

Level based dimension

Hi All,
I have requirement to implement level based hierarchy using the fields from three different dimensions. The three columns are in three different tables. On all the examples I have seen all the components/fields for level based hierarchy are from one single dimension table( like country, region, state,district from Region table).Is there a way to create level based hierarchy from different dimension tables.
Thanks,
Virat

Hi All,
After I created the level based hierarchy dimension for logical table which have 3 LTS. I am getting the following warning.
"Logical table hierarchy has a source D1 that does not join to any fact source."
Thanks,
Virat

Querying Levels in Dimensions joined to the Facts

I created a location dimension using the standard levels, i.e., region > subregion > country > state > location_id. I then attached it to a sales fact that had the location_id as the key, but when I tried to query the cube by it's levels the only level I see is the location_id level which is at the state. None of the other levels appear or are queryable when I do something like:
SELECT * FROM vw_SALES_CUBE A, vw_LOCATION_DIM B
WHERE A.LOCATION_DIM = B.DIM_KEY
AND A.LEVEL = 'COUNTRY'
Only one level comes up although in the location_dim all the other levels exist the join does not carry them over. The data for the levels appears in the COUNTRY_LONG_DESCRIP column and not in the LEVEL column.
What am I doing wrong. Are there other objects I need to create like an MV.
jrod

I was thinking that is if I created a cube such as the one described in the thread and that I did a query along the LEVEL_NAME that the cube would fetch the data without the need for me to create say MV's aggregateing the data. For example,
/* The following is a basic query against a fact table */
SELECT T.CALENDAR_YEAR_DSC TIME, SUM(F.SALES) SALES
FROM TIME_DIM T, UNITS_FACT F
WHERE T.CALENDAR_YEAR_DSC IN ('2005', '2006')
AND T.MONTH_ID = F.MONTH_ID
GROUP BY T.CALENDAR_YEAR_DSC;
/* The next query fetches the exact same results from a cube using filters: */
SELECT T.LONG_DESCRIPTION TIME, F.SALES SALES
FROM TIME_CALENDAR_VIEW T,
PRODUCT_PRIMARY_VIEW P,
CUSTOMER_SHIPMENTS_VIEW CU,
CHANNEL_PRIMARY_VIEW CH,
UNITS_CUBE_VIEW F
/* Apply filters to every dimension */
WHERE T.LONG_DESCRIPTION IN ('2005', '2006')
AND P.LEVEL_NAME = 'TOTAL'
AND CU.LEVEL_NAME = 'TOTAL'
AND CH.LEVEL_NAME = 'TOTAL'
/* Join dimension views to cube view */
AND T.DIM_KEY = F.TIME
AND P.DIM_KEY = F.PRODUCT
AND CU.DIM_KEY = F.CUSTOMER
AND CH.DIM_KEY = F.CHANNEL
ORDER BY TIME;
In these two queries I fetch the same grain. So why is it that the cube has not precomputed these factors. What do I need to do this?

Restrict the number of detail level of dimension hierarchy

Hi,
I must restrict the hierarchy level on each answers report differently.
For Example,
For Report A -> Region - Country-City
For Report B -> Region - Country
is there any way to do that using one dimension table?
Thanks..

Hi,
From one dimension table you can create a alias table and from it create 2 hierarchy levels by giving different names.
One should look like Region-->Country-->City
second hierarchy Region-->Country
This way you can create 2 sheets for the users,so any one can be applied drill path.
Hope it helps you.
Best Wishes,
Kranthi.

Bridge to heirarchy level of dimension

Hi,
We have a fact table with sales records and customer dimension related to it.
The customer dimension has customerID as its PK. It also has at attribute of Customer Group, so several customer can belong to one customer group.
Now I've added a bridge table to connect a Conference dimension to the Customer Dimension (many to many) but if I join it by customer ID (not by group) then when slicing the cube by conference it only gives me the sales of the specific customers that participated
in the conference, while I would actually like to view sales of all the customer GROUPS that participated. (But I can't join the bridge on groups since group is not PK of customers dimension).
What is the correct procedure for this?
Thanks
Namnami
please help-

Hi,
From one dimension table you can create a alias table and from it create 2 hierarchy levels by giving different names.
One should look like Region-->Country-->City
second hierarchy Region-->Country
This way you can create 2 sheets for the users,so any one can be applied drill path.
Hope it helps you.
Best Wishes,
Kranthi.

Question about Level Meter Plug in

I know how to change the channel meter between pre/post fader metering is there a way to do this with Logic's Level Meter plug in and with Inspector?

Plugins are always pre-fader, as the audio path hits the plugins and then goes into the fader.
What you'd have to do is route your audio through a fader (eg aux channel) to control the level, and then leave the fader on your output set to 0dB and meter in your plugins on that.

About Level Psuedo column

Hi all,
can any one explain the query how it is working internally.
I could not get the logic of it and i tried and surfed many sites, all the sites are giving the query but no one explained how it is working.
how will you get the nth highest salary ?
select * from emp where sal in (select max(sal) from emp where level = &level connect by prior sal > sal group by level);
Please help me.
Regards,
Sri Ram.

Hi,
Sri Ram wrote:
i want to know how the query is getting executed.If a row is in the result set because it meets the START WITH condition, then it has LEVEL = 1.
If a row is in the result set becuse it (together with some row that has LEVEL = N) meets the CONNECT BY condition, then the new row has LEVEL = N + 1.
If there is no START WITH clause, then every row in the table is counted as meeting the START WITH conditiion, and so every row in the table is in the result set once with LEVEL = 1.
Let's simplify the problem a little by including only deptno=20. That is, let's only work with the rows produced by:
CREATE OR REPLACE VIEW emp_20 AS
SELECT       ename, sal
FROM       scott.emp
WHERE       deptno     = 20;so the data is:
ENAME             SAL
SMITH             800
ADAMS            1100
JONES            2975
FORD             3000
SCOTT            3000To understand any query, look at its sub-queries and make sure you understand them first. Run just the sub-query, simplified, if necessary, and showing any extra expressions that will help you understand it. In this case, the quesry contains the following sub-query:
     select        max(sal)
     from        emp_20
     where        level = &level_wanted
     connect by      prior sal > sal
     group by level
)That's a lot to understand a once. Let's simplify it, by removing the GROUP BY. Of course, that means we won't be able to use aggregate functions like MAX, so let's display their arguments, instead. Also, let's start by not using a WHERE clause. Instead, let's display the expression used in the WHERE clause. When trying to understand a CONNECT BY query, it can be very helpful to include SYS_CONNECT_BY_PATH in the output.
So let's run just this query:
WITH     in_subquery     AS
     select        sal          -- originally was max (sal)
     ,       ename
     ,       LEVEL
     ,       SYS_CONNECT_BY_PATH (ename, ',')     AS path
     from        emp_20     -- originally was xcott.emp
--     where        level = &level_wanted
     connect by      prior sal > sal
--     group by level
SELECT     *
FROM     in_subquery
;Output:
SAL ENAME LEVEL PATH
800 SMITH      1 ,SMITH
2975 JONES      1 ,JONES
800 SMITH      2 ,JONES,SMITH
1100 ADAMS      2 ,JONES,ADAMS
800 SMITH      3 ,JONES,ADAMS,SMITH
3000 SCOTT      1 ,SCOTT
800 SMITH      2 ,SCOTT,SMITH
2975 JONES      2 ,SCOTT,JONES
800 SMITH      3 ,SCOTT,JONES,SMITH
1100 ADAMS      3 ,SCOTT,JONES,ADAMS
800 SMITH      4 ,SCOTT,JONES,ADAMS,SMITH
1100 ADAMS      2 ,SCOTT,ADAMS
800 SMITH      3 ,SCOTT,ADAMS,SMITH
1100 ADAMS      1 ,ADAMS
800 SMITH      2 ,ADAMS,SMITH
3000 FORD       1 ,FORD
800 SMITH      2 ,FORD,SMITH
2975 JONES      2 ,FORD,JONES
800 SMITH      3 ,FORD,JONES,SMITH
1100 ADAMS      3 ,FORD,JONES,ADAMS
800 SMITH      4 ,FORD,JONES,ADAMS,SMITH
1100 ADAMS      2 ,FORD,ADAMS
800 SMITH      3 ,FORD,ADAMS,SMITHThere is no START WITH clause, so every employee appears once on LEVEL=1.
The CONNECT BY condition is "prior sal > sal", meaning that row p will be considered a parent of row c when p.sal > c.sal.
Let's look at the employee named JONES. the result set has the following rows with ename='JONES':
SAL ENAME LEVEL PATH
2975 JONES      1 ,JONES
2975 JONES      2 ,SCOTT,JONES
2975 JONES      2 ,FORD,JONESWe see that JONES is in the result set once with LEVEL=1(becuase there is no START WITH clause). JONES also appears as the child of SCOTT (because SCOTT has a higher sal than JONES) and again as a child of FORD (for the same reason). FORD was in the result set with LEVEL=1, and a row for JONES joined the result set at then next highest LEVEL, becuase that row met the CONNECT BY condition: FORD's sal (3000) was higher than JONES's sal (2975). Looking at this output, we can see that there is a chain of employees, each with a sal greater than the next employee. JONES appears in such a chain with LEVEL=2, so JONES has the 2nd highest sal in that chain, or JONES's sal (2975) is the 2nd highest sal in that chain.
Look at another employee, say ADAMS. Do you understand why all the rows with ename='ADAMS' are there, and what all the columns in the output mean on those rows?
When you understand this sub-query, let's modify it, making it a little more like the original. Let's restore the WHERE clause, so the query is now:
WITH     in_subquery     AS
     select        sal          -- originally was max (sal)
     ,       ename
     ,       LEVEL
     ,       SYS_CONNECT_BY_PATH (ename, ',')     AS path
     from        emp_20     -- originally was xcott.emp
     where        level = &level_wanted
     connect by      prior sal > sal
--     group by level
SELECT     *
FROM     in_subquery
;and the output for any given value of &level_wanted will be something like:
SAL ENAME LEVEL PATH
800 SMITH      2 ,JONES,SMITH
1100 ADAMS      2 ,JONES,ADAMS
800 SMITH      2 ,SCOTT,SMITH
2975 JONES      2 ,SCOTT,JONES
1100 ADAMS      2 ,SCOTT,ADAMS
800 SMITH      2 ,ADAMS,SMITH
800 SMITH      2 ,FORD,SMITH
2975 JONES      2 ,FORD,JONES
1100 ADAMS      2 ,FORD,ADAMSAgain, study the output, and make sure you understand it.
Do you see jow each sal shown is the 2nd highest in some parent-child chain?
Do you see how heach sal shown might possibly be the 2nd highest sal?
When you do uderstand that query, make it still more like the original. Restore the GROUP BY clause and the MAX function. Actually, all you need is the MAX function. Since the WHERE clause guarantees that all rows in the ungrouped result set have the save LEVEL, then saying "GROUP BY LEVEL" isn't doing anything, and it doesn't make any sense. As Whitehat pointed out, the whole approach doesn't make any sense. This is a complicated and inefficient way to get the results you want. Whitehat showed a much better way, however, that solution was for the N-th highest paid employee. When there are ties (mutliple employees with the same sal), this will not be the same as the employee(s) who have the N-th highest sal, which is what the query you posted shows. Here's a better way to do what your query is doing:
WITH     got_r_num     AS
     SELECT     emp.*
     ,     DENSE_RANK () OVER (ORDER BY sal   DESC)     AS r_num
     FROM     scott.emp
SELECT     ename, sal     -- list all columns wanted
FROM     got_r_num
WHERE     r_num     = &level_wanted
;

About the theme Dimension "Today"

Hello,
The Dimension theme "Today" by BB does not get refreshed properly.
Even after the Messages are deleted from the messages list and changes made in the Calendar, it does not reflect in the theme.
Just for the info,
I am on 4.5.0.110 on BB 8310.
Thanks
Anurag

Hello there and Welcme to the Frums!
Did you find out the answer to your question?
http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB14932&sliceId=2&docTy...
http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB14646&sliceId=1&docTy...
Message Edited by cathlabnurse on 01-18-2009 06:25 PM
Nurse-Berry
Follow NurseBerry08 on Twitter

Question about levels

Hi. I am enjoying myself playing with Logic Pro x. I have decided that reproducing songs is a good way to teach myself how it all works before I try something original. I am reproducing Charriots of Fire by the Royal Symphonic Orchestra at the moment. I have left the start off at the moment as it is orchestarl and you have to bring the volume in and then down again while holding a nice full strings. Can't work out hopw to do that. Any tips would be gratefull.

It's time to read about Automation
http://help.apple.com/logicpro/mac/10/#lgcpb1a1ea03
Then you can use track automation to control the volume for that track or tracks...

About Surrogate Key and Dimension Key on OWB 10.2

Hi, everyone.
I am using OWB 10.2 and I have a question about Surrogate key and Dimension Key.
I indicated the foreign key as VARCHAR2 type in Fact Table and Dimension Key as VARCHAR2 type is operated as Primary key in Dimension Table. I made Single Level in Dimension Table.
I know that Dimension Key stores the surrogate ID for dimension and is the primary key of the table. Also, Surrogate ID should be only NUMBER type.
So, in this case, Surrogate ID is NUMBER type
Dimension key should be NUMBER type to store the surrogate ID.
But, Dimension key also should operate the primary to relate Foreign key as VARCHAR2 type.
How I can solve this confusing condition?
Please let me know that.
JWS

Hi JWS,
From a SQL point of view it should not be a problem to join a NUMBER field to a VARCHAR2 field because during execution there will be an implicite cast for the NUMBER value to a VARCHAR2 value. See the example below.
SELECT * FROM DUAL
WHERE 1 = '1'From an OWB point of view it is not possible to have a Dimension with an NUMBER value Key that has a relation to a VARCHAR2 value Foreign key in a Fact table. This is caused due to the creation of a Fact table in OWB in which the Foreign keys in it are build from de Dimension tables that refer to them.
You will loose the reference to the Dimension when changing the type of the Foreign Key.
To resolve this issue I would advise you to use a Sequence that generates your Surrogate Key (NUMBER type) for the Dimension table and store it in the Primary Key Column (VARCHAR2 type).
When validating the mapping you will get a warning, but when executing this should give no problems.
Regards,
Ilona

About levels in dimensions

Similar Messages

Maybe you are looking for