Fact table enriched with hierachy information
Hi Guys,
I have a fact table design question.
The fact data table (oracle10g) on bottom level RelationshipManager (RM) contains the data columns
for the RM dimension:
FACT TABLE
ID¦RM¦DEPARTMENT¦AGENCY¦REGION¦SALES
1---23--Bronx------------NY---------US-------23232
2---24 ---------------------NY---------US-------87878
3---25-----------------------------------US------ 9999999
This means the fact has been enriched with hierachy information, this is not whats usually done.
Why have I done it? Because the RM is not necessarily always part of a department BUT can also
be directly placed under an agency or a region (agency or region leads).
Have I made the right choice by chosing to enrich the fact table? I could have also build a snow flake
schema by storing hierachy information in a seperate table.
Thanks.
with your problem, it might be best to split the dimension into multiple dimensions or multiple attribute dimensions with default values where you do not have a value for example set up RM with a N0_RM and when you don't have data load it there. If I'm looking at this correctly, the problem it appears you have is you have an inconsistent hierarchy. where the rollups can change. having them in the same dimesion would be problematic. If therewere consistancy then you could add members into a single hierarchy something like
US
--No_State
--NY
-----Bronx
------RM23
------No_RM
but from your example I don't see it. If they are seperate dimensions(not attribute dimensions) then you could load based on date. If they are attribute dimensions, then look at varying attributes
Similar Messages
-
NQSError: 14020 : Fact Table Incompatible with Query Request
Hi All,
I am trying to add a new join to existing fact and dimension tables.
These tables are already part of some star schemas.
Now when I add the join , RPD doesn't show any consistency errors/warnings but when I create an analysis in OBIEE 11g, Measure from fact shows only null.
When I looked at the log, the physical query just has a select statement querying the dimension table and following message :
"COUNT converted to NULL because [nQSError: 14020] None of the fact tables are compatible with the query request COUNT:[DAggr(CF_FACT1.COUNT by [ CD_DATE_4.DATE_KEY.. "
Has anyone encountered similar problem ?
Few threads spoke about settign the content level but its not set for any date dimension we are using but it still works. Facing this problem only for the new join I am trying to add now.
Thanks for any pointers
SujanaBack up your repository before following these steps:
1 Reduce the problem report to minimum number of columns required to generate the error. This will usually identify which dimension and which fact are incompatible.
2 Open the repository in the Administration tool and verify that the dimension and fact table join at the physical layer of the repository
3 Verify that there is a complex join between the dimension and the fact in the business layer.
4 Check the logical table sources for the fact table. At least one of them must have the Content tab set to a level in the hierarchy that represents the problem dimension. This is usually the detailed level.
5 Check the logical table source Content tab for the dimension table. Unless there is a valid reason, this should be set to blank.
6. Save any changes to the repository. -
Multiple Date Fields (Fact Table) - Linking with Time Dimension
I have a fact table that has multiple date columns.
I can make a time dimension, but it has to be joined to a particular date column. This becomes difficult because of the limit in having multiple date fields reference one time dimension. I can see possibly
creating a date table which contains all dates, link to fact as well as time dimension table. I am trying to better visualize the table layout on this one. Or are there possibily better ways of looking at this senerio
Any idea'sFigured this one out; going to use one time dimension - what looking too much into the details in regard to this scenerio
-
Using 2 fact tables with different granularity against calendar dimension
Hello gurus,
I have a requirement to provide a report to show the consumption of available capacity per month and also YTD.
I have two fact tables:
Fact table ‘Capacity’ with columns:
- Site_id
- Month_id
- Capacity
Ie.
001, 2010M01, 50
001, 2010M02, 50
001, 2010M12, 75
002, 2010M01, 60
002, 2010M02, 65
002, 2010M12, 80
Etc
Fact table ‘Consumption’ with columns
- Site_id
- Day_id
- Consumption
Ie
001, 20100101, 2
001, 20100102, 3
001, 20100131, 1
001, 20100201, 5
001, 20100212, 6
001, 20100228, 4
Etc
As can be see above, my ‘Capacity’ table contains monthly volumes, and the ‘Cunsumption’ table contains daily volumes.
My Calendar dimension is straightforward:
Year
Quarter_id
Month_id
Day_id
Ie
2010, 2010Q1, 2010M01, 20100101
2010, 2010Q1, 2010M01, 20100102
2010, 2010Q1, 2010M01, 20100103
2010, 2010Q1, 2010M01, 20100104
Etc
The MfgSite dimension is also simple:
Site_id
Site_name
Group
These are the steps I have taken sofar:
- Imported the four tables
- Created following joins:
MfgSite.Site_id = Capacity.Site_id
MfgSite.Site_id = Consumption.Site_id
Calendar.Month_id = Capacity.Month_id
Calendar.Day_id = Consumption.Day_id
- Created Business Model Diagram in BMM
- Created Calendar hierachy:
Year, Quarter, Month, Day
- Created MfgSite hierarchy:
Group, SiteName
- Setup Logical Table Source / Content settings as follows:
Fact table Capacity:
Dimension MfgSite: Logical Level = Site
Dimension Calendar: Logical Level = Month
Fact table Consumption:
Dimension MfgSite: Logical Level = Site
Dimension Calendar: Logical Level = Day
- Set Default Aggregation Rule to Sum on Logical Columns:
Capacity.Capacity
Consumption.Consumption
- Created following YTD Logical Columns:
YTDCapacity = TODATE(Capacity.Capacity, Calendar.Year)
YTDConsumption = TODATE(Consumption.Consumption, Calendar.Year)
- Created Presentaion layer
I then built a few reports to test it out and found that I have an issue with the Capacity object: When I build a simple report to show capacity per month:
SiteName, Month, Capacity
the capacity for each month is multiplied by the number of calendardays in that months, so I get
Site Month Capacity
001 2010M01 1550 (= 31 x 50)
001 2010M02 1400 (= 28 x 50)
Etc
In addition, when I add YTDCapacity to my report, the report fails with the following message:
Unable to navigate requested expression: ToDate(Capacity:[DAggr(Capacity.Capacity by [ Calendar.Year, Calendar.Month_id, MfgSite.Site_id, MfgSite.SiteName] )], [Level Year]). Please fix the metadata consistency warnings. (HY000)
Did I miss any steps? Any help is greatly appreciated!
Thanks!
Randallhi in the capacity fact table remove the level set for the calendar dim and see.
-
Fact tables with different granularity
We currently have 3 dimensions (Site, Well, Date) and 2 fact tables (GasEngine, GasField), both having granularity of a day.
GasEngine is linked to Site and Date
GasField is linked to Site, Well and Date
We now have a requirement to make the GasEngine fact table have granularity of an hour but keep
GasField at a day.
We therefore must include a new Time dimension, which would only be linked to GasEngine.
Is it ok to have a DW with these two fact tables having different granularity?
And would we therefore require two separate cubes for querying this data?Hi Rajendra and Visakh16,
Based on your input provided to this thread, I would like to ask a question just to fine-tune my knowledge regarding data modelling. In Darren’s case I guess his date dimension only store dimension records up to day level granularity. Now the requirement
is to make the “GasEngine” fact table to hold data granularity of an hour.
Now based on Rajendra’s input
“Yes, you can have. but why you need new time dimension, I recommend, make GasEngine fact to
hour granularity.”
How Darren could display data for each hour without having a time dimension attached to GasEngine fact table? With the existing date dimension he ONLY can display the aggregated data with the minimum granularity of day level.
Now anyone can modify the date dimension to hold time records which will complicate the date dimension totally. Instead why Darren cannot have a separate time dimension which hold ONLY time related data and have a timekey in GasEngine fact table and relate
those tables using the time key? This way isn’t Darren’s data model become more readable and simplified? As we provide another way of slicing and dicing data by using a time dimension I do not think Darren’s cube becomes a complex STAR schema.
I could be totally wrong therefore for the sake of knowledge for Darren and me I am asking the question from both of you.
Best regards…
Chandima Lakmal Fonseka -
Cubes with different dimensions based on the same fact table
I have a fact table (f_a) with three dimensions (dim_a, dim_b, dim_c) and a one measure (m_a).
Is it possible to create cube with only one dimension (dim_a)?
Data for other two dimensions (dim_b, dim_c) should be aggreagated together.
Of course i can create second fact table with only one dimension, and then creating that cube would be no problem.
But is it possible doing this directly from the primary fact table (without creating second fact table)?
Raf
PS:i use AWM 9.2 to create target cubes. Source cubes i create with OEM 9.2At the beginning i was confused by the numberous kind of cubes...
for example when i created cube in MS i just designed cube, picked fact table, and that's all. In Oracle firstly i create project of cube (first cube) in OWB. Then i export it to the OLAP Catalog (second cube). That cube in OLAP catalog is a source cube for the AW cube (third cube). Then i need to enable AW cube for OLAPI by creating another cube in OLAP Catalog (i use 9iR2, so OLAPI doesn't have direct access to AW cubes).
I spent much time until i could see my first sample cube in Discoverer or Excel as a final user should see it. :-)
Now i'm facing another problem - when you redesign cube (for example add another dimension), you can't just "refresh" it as it was in MS. You have to delete old cube and create new one. And deleting cube isn't so simple (i'm not sure which elements i should delete).
For testing and learning purposes i just create every cube in seperate AW. deleting whole AW is much simplier that deleting one cube.
Raf -
How to create a ROLAP Cube that has two fact tables.
I want to know if it is possible to create a ROLAP Cube with two fact tables.
Suppose that I have these two star schemas:
The first star schema has only a measure and a time dimension. The time dimension has three levels (Year -> Month -> Day)
The second star schema has the same measure of the first schema and a time dimension. In this schema the time dimension has only two levels (Year -> Month). The values of the measure of this schema come from the first schema, this is, the value of the measure for a defined year and month results of the sum of all fact values of the first schema, that have the same year and month.
I want to know if is possible to create a ROLAP cube that can get the information of the two star schemas, according to the level that the user are consulting.
For example, if the user consults the cube with "OracleBI Spreadsheet Add-In", and if the user is consulting the first two levels (Year and Month), then the ROLAP cube would get the information of the second star schema.
But if the user does a drill down in a month to get information of the days, then the ROLAP cube would get the information of the first star schema.
Is it possible to do this?
Regards,
Rui TorresI'm not exactly sure what you want to do. Sorry if I get this wrong.
You have two fact tables, one with data values at the day, month and year levels and a second fact table with data values at just the month and year levels. If this is the case, in the CWM2 APIs or OWB Paris, you would create a view that joins the two tables together and then map this view to the ROLAP cube.
For CWM2 details, please refer to the Oracle OLAP Reference. -
SQL Server 2k - Pulling from 2 fact tables causes error
Trying to create a simple RPD as follows:
1 Dimension with Key Fund_ID
2 Fact tables, each with a Key Fund_ID
Created a Physical Layer, connecting Dimension to each Facts based off Fund_ID (One to Many)
Business Model Layer, connected Dimension to each Fact using complex join.
In Answers, the following is true:
Querying Dim and Fact Table A returns Data
Querying Dim and Fact Table B returns Data
Querying Dim AND Fact Table A, AND Fact Table B returns the following error message:
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table A) does not contain mapping for [table B]. (HY000)
It appears to be complaining that it cannot map the fact tables to each other. I tried mapping the two fact tables together (even though that doesn't make DW sense), and the RPD won't validate.
I'm wondering if this is a bug connecting to SQL Server. We do the majority of our RPD development against ORACLE, and this is our first attempt at using SQL Server as a source.
Does anyone have any suggestions on this?
thanksI doubt it very much its DB specific, the error is from the BI Server ([nQSError: 15018]) rather than SS.
Have you got a dimension hierarchy ? Are your content levels set for all logical tables, do you have 2 logical facts or 1 combined logical fact ? What do your Logical Table sources look like (ie how many per logical table, conent levels ?joins within the LTS?)
I would guess the problem lies in your BMM layer. But should check, is the conformed dimension joined to both fact tables in the physical layer or have your aliased it ? -
Hi
Can anybody tell me how the BWA decides when a fact table index gets split into multiple parts? We have a number of very large cubes that are indexed and some have a fact table index that consists of one logical index which is made up of multiple physical indexes but other, similar sized cubes, just have one very large physical index for the fact table.
With the one very large physical index we seem to get an overload problem but when they are split into multiple parts we don't.
Thanks
MartinHi Martin,
this depends on the reorg config and the attribute of the index. You can manually trigger a splitting of an index via command 'ROUNDROBIN x', x stand for the number of parts which the index will be split to. Therefore you have to go into trexadmin standalone tool -> landscape right click on index -> split/merge index...
If you want an automatically split, you have to setup your reorg settings. Goto trexadmin standalone tool -> tab reorg -> options -> here you can choose the type of algorithm. Have a look into note 1313260 and 1163149.
Do you have a scheduled reorg job?
Regards,
Jens
PS: Every black box can be understood... -
All -
I have a TSR dimension data (1 of 12 dimensional attributes) in our forecast fact table which gets updated monthly in our source system and we have to reflect this in our BPC system. What is the best method of updating this data in BPC?
1. Can I update the TSR directly in the forecast fact table and reprocess the application to reflect this in the cube?
2. Do I have to negate that entire fact table row with the old TSR and insert a new row with the new TSR and process the cube?
3. Any other method?
Thanks for your help.You need to explain your requirement a bit more. Why you want to add type or rejection reason in fact table.
In general you should avoid adding textual data in fact.
Fact tables are only supposed to store keys and measures. It can hold textual data in case of degenerate dimension ( i.e if the number of records are same in dimension as well as fact ).
Type or Rejection reason are going to have much less records. You can create a new dimension for them having probably 20 or 30 records.
Disadvantages of adding textual data in fact is, once the fact has millions of records the fact table updates are going to take huge time and also your reports will take long time.
If you have a rejection reason dimension with some 20 records, you can use rejection reason in prompts.
But if the same rejection reason is coming from fact table your prompts performance is going to be very slow since it has to fetch 20 distinct records from millions of records.
Consider these before adding textual data in facts.
Thanks
Edited by: Maqsood Hussain on Dec 5, 2012 9:40 PM -
OWB Newbie - Joining Dimensions to Fact Tables
Hello Forum,
This may seem like a simple question, but the documentation is so lacking that I can't seem to find the answer to "how does the tool" work.
I am creating a simple data mart starting with a star schema and choosing a deployment option of ROLAP.
When using the OWB Tool to create dimensions and fact tables, do you need to define your primary business key (coming from your source system) in each fact table for each dimension that will join to that fact table? I am assuming yes, at least at the lowest leaf level of the dimension hierarchy in this case Store_ID. How else would you be able to correctly join a particular sales order record to the store that it was sold in? a simple query that we know our users will execute for reporting purposes. To make myself clear here is a simple example:
Dimension = Store
Hierarchy = Store ----> Sales Territory ---->Region ----->Country
Attributes = Store ID (primary business key), Store_Name, Sales_Territory_ID, Sales_Territory_Description, Store_Manager_Name, Store_Location etc.,
Cube or Fact Table = Sales Orders
Measures = sale_price, quantity, drop_ship_cost, sales_tax, etc.,
Do I also need to create an attribute for Store ID so that when I load each sales order record into the fact table along with it comes it's proper Store ID?
I understand how the tool uses the surrogate key and business identifier to create a foreign key look-up from dimension to fact table and pull in the correct store description (i.e. name) but unless you have the Store ID as part of the sales record being loaded into the fact table I don't see how the you can traverse the table and join a sales order to it's proper store?
Can someone who is farther along in the process or has more experience with other components of the tool confirm my assumption or set me straight on how the tool accomplishes this?
thanks
monalisaHi Monalisa, I'll reply assuming your using OWB 10gR2.
First off, for each of the dimensions, you'll define a business key (as you noted below). Then, when you define the cube object, you'll tell it which dimensions you are using, along with the measures you will be storing.
When you drop a "cube" object into a map, it will show the measures, but it will replace the dimensions with their natural keys. I.e. in your example below, if your sales order cube had ONLY the store dimension, then the cube object will show up in a mapping with the measures of sales_price, quantity, drop_ship_cost, etc., but instead of showing the dimension for store, it will instead show the natural key Store_ID. When you map your data to load (which should be by store_id), OWB will automagically look up the proper dimension keys and do everything else for you.
Hope this helps!
Scott -
Cartesian product of three dimensions - fact table is too big
Hi, I need some advice with OLAP design. I have tables with orders, customers and product types. My problem is that I want to know amount of orders for every combination of customer - date since customer was created - product type. I also need to filter
days when no order was made and the opposite (by dimension). Also customer have some interval of time when he is considered as a new customer and I need to filter this customers too (again by dimension).
Now I have got fact table filled with every combination of customer/product type/date and the number of orders with the bit flag - was a new customer. Problem is that I have aprox 100k customers, so this table has bilions of rows. Is there any other possible
solution? For browsing cube is used Excel where I cannot easily filter by measure/calculation.It seems like every customer is a new customer at some point in time. So, you should probably store first order date in the customer table. Depending on the Date (Period) selected , a customer will become new, active or inactive. Also, create measures for
new customer sales, old customer sales. i.e. First order date + 30 days of the customer is less than last date in the period selected, it is new customer sales. I would assume that it would be difficult to do it in cube. Did you
try to solve the problem using SQL queries?
Good luck.
Customer
First Ord Date
New customer till
Cust A
3/1/2014
4/1/2014
New Cust Sales
Old Cust Sales
Total Sales (New + old)
2014-01
2014-02
2014-03
10
10
2014-04
20
20
2014-05 -
OBIEE Hitting incorrect fact table
Hi,
I have two Fact tables joined with 3 Dimensions..
F1 - D1, D2, D3
F2 - D1, D2, D3
Now I added another dimension D4 and joined it with F2.
While taking D1, D2 D3 while it use to get F1 in the Query now, it started taking F2 and showing incorrect results.. How can this be fixed?Dont blame OBIEE!! You haven't configured it correctly.
Try to set implicit fact column setting on Subject area. That might help you.
If helps mark -
Hello Gurus,
Can you please tell me why fact table has total column limitation as 256 and why a dimension table has 16 characteristics limitation?
And in Oracle or in DB2 limits are more than this then what is the advantage of using SAP BW/BI?
Thank you in advance
LiliHi..
The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the fact-table tablespace with the assigned data class DFACT is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.
With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.
The width of a data record depends on the number of dimensions and the number of key figures in the InfoCube. A dimension key field uses 4 bytes and a decimal key figure uses 9 bytes. If, for example an InfoCube has 3 standard dimensions, 7 customer dimensions and 30 decimal key figures, a data record needs 10 x 4 bytes + 30 x 9 bytes = 310 bytes. In a 32K block, 32768 bytes / 310 bytes could write 105 data records
Hopes this helps.. -
SSAS Tabular - Vertically partitioned Fact Table Relationships
Hi All, I have a very wide (300 column) fact table and hence it is partitioned into 2 fact tables vertically with the common key in both tables for relation (1:1). Both the tables have some measures and degenerate dimensions to be used for analyisis.
How should the data model look like? I am stuck because the bi-directional relationships doesnt seem to be supported and only one direction works when degenerate dimensions are used.
Also, these two fact tables are related to some common dimensions and when i connect all of them together, some of the relationships get deactivated due to circular naure of relationships. Using USERELATIONSHIPS is going to be very timeconsuming considering
the number of measures.
What is the guidance around modelling vertically partitoned fact tables? Do I combine both the tables into one wide table using a View or Query? Any help appreciated.
Thanks, Ashish SinghHi Thomas, Unfortunately I do not have any control over the DW design and the client says that they require most of the columns for analysis. I do not want to combine the fact tables into a wider table but stuck with the relationship design in Tabular mode.
1) Bi-directional relationships are not supported. So, if both the fact tables have degenerate dimensions on which the mesaures have to be analyzed, it cannot work because the relationships are unidirectional in tabular mode.
2) Relationships get deactivated. Since both the tables are connected to each other using a KEY column, any attempt to connect both the tables to some common dimension results in INACTIVE relationships which needs either using USERELATIONSHIP or importing
the same table again with a different alias which complicates the model.
3) Inferenced relationships cant be modelled. If Fact1 is connected to a dimension, the measures of Fact2 cannot be analyzed on that dimension even though Fact1 and Fact 2 are connected using a 1:1 relationship.
All these design challenges make me lean towards using a SQL View and joining the 2 Fact tables in the Tabular model so that I could provide the users with the analysis they require using the current DB structure. Is there a different approach to achieve?
Any better ideas would be heplful.
Thanks, Ashish Singh
Maybe you are looking for
-
how do I share movies/music between my computers. I have opened shared on both computers and both are on, but i am not able to drag anything from one to the other. Does anyone know where the settings button is on the bottom of the itunes screen?
-
How do I add video to be hosted directly on my MUSE site without using a third party like Vimeo / You tube etc ?
-
Hi , Is there any functional module or table available to fetch vendor number when i pass logical system name and Company code? The scenario is.. through function module 'BBP_READ_ATTRIBUTES'. i can get logical system name and company code fo
-
Handling Multiple 834 documents through B2B
Hi, We are trying to send a daily reconciliation transactions HIPAA file using 834 format. We would like to know how to concat each individual transactions into one 834 EDI file for daily reconciliation. We tried the batching option however we found
-
Relation B/W tax and pricing condition types
HI friends I want to know relation b/w tax and pricing condition types. Here, i think we are giving relation in pricing procedure, how we are giving that relation, what is that mean. How sys will carry the values from tax condition types to pricing c