Fact Tables without Dimension Tables.

Hi,
I am currently working on a project where a data warehouse is being developed using an application database as the source. Since the application database is already normalised, the tables are being loaded in as they are and the consultant involved is creating
data marts for them. I have asked about why he is not creating separate dimension and fact tables as data marts, and he has told me that he will create a fact table with the dimensions as column names without any dimension tables created as you might expect
as per star/snowflake schema.
Is this right, as I always thought you had to have dimension and fact tables, especially if you want to start using SSAS?
Regards,
W.

create a fact table with the dimensions as column names without any dimension tables created as you might expect as per star/snowflake schema.
This is the trouble with denormalization: where is the stopping point?
If the data warehouse is the source for SSAS OLAP cubes, it is better to go with the usual star schema.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Similar Messages

Fact table without dimension table

is it possible to build a fact table without any joining dimension table?
I found that in this case an error is issued.
thanks !!

Yes, you can but you must create a fake join with another table.
OBIEE ask always in the Business Model Layer minimum a fact table and a dimension.
In the presentation layer, you drag only the fact table column and it will work.

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Dimension values without data in a fact table

I have an ODS system and a Data warehouse system
I have a Sales fact table in the ODS system and I have these fields:
SALES
ID_CUSTOMER (PK),
ID_MODEL (PK),
ID_TIME (PK),
SALES,
QUANT_ART,
COST
Then in some records in the fields ID_Time or ID_Model or ID_Customer I donât have values (NULL) because in the transactional systems these record donât have values (NULL).
The users want to generate aggregate reports with the Sales table...
The question is:
I have to put a âdummyâ value in the dimensions Customer, Model and Time (for example â0â) and put this value in the fact table if the dimensions fields have NULL values????
Or I have to leave the NULL values?
What is the best choice? Why?

There's often some specific reason why these values don't exist, such as the record being a manual adjustment to sales (for example a journal voucher). In these cases it can be helpful to have a flag column to indicate this, so that when a user comes across a bunch of sales with a Store Name of "Unknown" or "Not Applicable" they can also look at the reason for this unusual entry.

Relationship between Dimension without linking Fact table

Hi,
My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
including any measures from fact table .
Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but not linked to each other directly but can I get right result when I want to know what are the manufacturer for each product? or list of
customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
regards
Sanjoy ghosh

Hi Sanjoy -
The answer to your questions depends on your dimensional design and exactly what the fact table represents. Fact tables naturally capture the intersection of the different dimensions. This is true whether you physically implement a
PK - FK relationship in the relational db.
In your case, since customer is involved, sounds like a sales transaction fact. If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely. Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
across to product. If you need to solve this question, you have some other options:
- flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
- embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
to be flattened onto the product)
- build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates. This would allow you to capture rich details about each dimension separately
and use the factless fact to record)
Let me know if that helps.
Brent Greenwood, MS, MCITP, CBIP
// Please mark correct answers and helpful posts //
http://brentgreenwood.blogspot.com

Transaction data can be loaded into the Fact table without loading the

Transaction data can be loaded into the Fact table without loading the corresponding master data (Example : Sales analysis transaction data can be loaded without populating any of its dimensions master data)
a. True
b. False

Hi Kutti,
True - You need to select the option in the infopackage - alwyas load even if no master data exists.
Bye
Dinesh

Join fact table with higher dimension level

how do i join fact tables with higher dimension levels with discoverer?
fact with detail at level C
measure X
dimension with
D->C->B->A
E->C
level
A B C
1------1------1
2------2------1
3------2------1
join between fact X and dimension level C
X=3*C because of sum(X) in discoverer and 3xC in dimension
is there a way to get correct values for X without creating a dimension like
D->C
E->

another way of asking this is whether you can create a summary table in Discoverer at a higher level than a dimension's fundamental grain. In other words - the summary examples in the documentation all describe leaving out one or more of your dimensions... they are either left in or completely taken out. But, some of the most effective summarization occurs when you summarize daily data to a monthly level. Assuming that I have a sales table (at a daily level, and a key value sales_date), and a table date_dim (primary key sales_date), I would like to create a summary sales_month_summary where the sales are grouped on month_year (which is a field in the sales_date table).
How is this done? I suspect that we can't use the date_dim table with the summary (due to the problems noted by the poster above). Do we have to create another table "month_dim"? Do we have to fold all of the desired date attributes (month, quarter, year) into the summary? Obviously we'd like to re-use all of the pertinent already existing date items (quarter, month, year, etc.), not recreate them over again, which would result in essentially two sets of items in the EUL. [One used for this month summary, and another used for the detail.]
I searched the forum - someone asked this same question back in 2000 - there was no answer provided.
The only other thought I have is to "snowflake" the date_dim into two tables and two folders, one at a date level, another at the month level. Then the detail tables can connect to date_dim (which is linked to month_dim), while the summary data can connect directly to month_dim.

What is correct way to join a start/end date driven dimension to a fact table in data foundation?

I have a bad universe or a data design issue.
Several versions of hierarchies reporting store entities in reporting Fact measures.
Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                            START_DATE
                                                                            END_DATE
                                                                            STORE_NUMBER
                                                                            ORG_HIERARCHY
                                                                            CURR_FLG   (Y/N)
Fact table :                                                         ORG_KEY
                                                                             CALENDAR_KEY
                                                                             TRANS_DATE
                                                                             $amount
Calendar Dimension:                                            CALENDAR_KEY
                                                                              DAY_DATE
                                                                               FY_WEEK          (201452)
                                                                                FY_PERIOD      (201412)
                                                                                FY_QUARTER   (201401)
                                                                                 FISCAL_YEAR    (2014)
Users WISH:
Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
Daily (Would be Calendar.Day_Date in Filter) ,
Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK as entered,
Month to date,
Year to date,
AdHoc queries.
My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail. I have not gotten @Prompts to work in joins, derived tables, etc. in the data foundation. Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked.
Please help!   ANY ideas would be appreciated.   .

{Note that abbrevations in brackets are just for short form further down the answer}
Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
Create an alias of Calendar Dim and call it Transaction Date (TD)
Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
The above predefined condition when added to your data query will return only yesterday's transactions.
However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
If you have any more questions about how this approach would work please shout.
As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

Problem with populating a fact table from dimension tables

my aim is there are 5 dimensional tables that are created
Student->s_id primary key,upn(unique pupil no),name
Grade->g_id primary key,grade,exam_level,values
Subject->sb_id primary key,subjectid,subname
School->sc_id primary key,schoolno,school_name
year->y_id primary key,year(like 2008)
s_id,g_id,sb_id,sc_id,y_id are sequences
select * from student;
S_ID UPN FNAME COMMONNAME GENDER DOB
==============================
9062 1027 MELISSA ANNE       f 13-OCT-81
9000 rows selected
select * from grade;
      G_ID GRADE      E_LEVEL         VALUE
        73 A          a                 120
        74 B          a                 100
        75 C          a                  80
        76 D          a                  60
        77 E          a                  40
        78 F          a                  20
        79 U          a                   0
        80 X          a                   0
18 rows selectedThese are basically the dimensional views
Now according to the specification given, need to create a fact table as facts_table which contains all the dim tables primary keys as foreign keys in it.
The problem is when i say,I am going to consider a smaller example than the actual no of dimension tables 5 lets say there are 2 dim tables student,grade with s_id,g_id as p key.
create materialized view facts_table(s_id,g_id)
as
select s.s_id,g.g_id
from   (select distinct s_id from student)s
,         (select distinct g_id from grade)gThis results in massive duplication as there is no join between the two tables.But basically there are no common things between the two tables to join,how to solve it?
Consider it when i do it for 5 tables the amount of duplication being involved, thats why there is not enough tablespace.
I was hoping if there is no other way then create a fact table with just one column initially
create materialized view facts_table(s_id)
as
select s_id
from student;then
alter materialized view facts_table add column g_id number;Then populate this g_id column by fetching all the g_id values from the grade table using some sort of loop even though we should not use pl/sql i dont know if this works?
Any suggestions.

Basically your quite right to say that without any logical common columns between the dimension tables it will produce results that every student studied every sibject and got every grade and its very rubbish,
I am confused at to whether the dimension tables can contain duplicated columns i.e column like upn(unique pupil no) i will also copy in another table so that when writing queries a join can be placed. i dont know whether thats right
These are the required queries from the star schema
Design a conformed star schema which will support the following queries:
a. For each year give the actual number of students entered for at A-level in the whole country / in each LEA / in each school.
b. For each A-level subject, and for each year, give the percentage of students who gained each grade.
c. For the most recent 3 years, show the 5 most popular A-level subjects in that year over the whole country (measure popularity as the number of entries for that subject as a percentage of the total number of exam entries).
I written the queries earlier based on dimesnion tables which were highly duplicated they were like
student
=======
upn
school
school
======
school(this column substr gives lea,school and the whole is country)
id(id of school)
student_group
=============
upn(unique pupil no)
gid(group id)
grade
year_col
========
year
sid(subject id)
gid(group id)
exam_level
id(school id)
grades_list
===========
exam_level
grade
value
subject
========
sid
subject
compulsory
These were the dimension table si created earlier and as you can see many columns are duplicated in other tables like upn and this structure effectively gets the data out of the schema as there are common column upon which we can link
But a collegue suggested that these dimension tables are wrong and they should not be this way and should not contain dupliated columns.
select      distinct count(s.upn) as st_count
,     y.year
,     c.sn
from      student_info s
,     student_group sg
,     year_col y
,     subject sb
,     grades_list g
,     country c
where      s.upn=sg.upn
and     sb.sid=y.sid
and     sg.gid=y.gid
and     c.id=y.id
and     c.id=s.school
and      y.exam_lev=g.exam_level
and      g.exam_level='a'
group by y.year,c.sn
order by y.year;This is the code for the 1st query
I am confused now which structure is right.Are my earlier dimension tables which i am describing here or the new dimension tables which i explained above are right.
If what i am describing now is right i mean the dimension tables and the columns are allright then i just need to create a fact table with foreign keys of all the dimension tables.

Best way to connect two fact tables when no conformed dimension exists

Can anyone please elaborate how would I connect two fact table without any conformed dimension. Let say FACTA, FACTB. FACTB is related to a dimension "StatusDim". I want to select the count of all FACTA item which are related to FACTB items with
a particular status. I have found the following article but just wondering whether it is the best practise to connect two fact tables directly.
http://bifuture.blogspot.com/2011/11/ssas-selecting-facts-with-reference.html
Thank you

Hi Ahsan,
After read the blog you posted, I think it's a pretty good solution to create a view in the relational database or a named query in the Data Source View containing as the the columns in FACTA and FACTB. Then build a dimension from it, setting the "Null processing"
property (you have to click the "plus" two times for the "Key Columns" property of the attribute in BIDS to access this property) to "UnknownMember". And then use this dimension for the many-to-many relationship. Dimensions from FactA can benefit of the reference
relationship between FactA and FactB and therefore a powerful solution it is.
Regards,
Charlie Liao
If you have any feedback on our support, please click
here.
Charlie Liao
TechNet Community Support

Dimension Table : Fact Table

Hi,
I have Y/Z InfoCubes in my BW, somebody telling that Cube Dimension data table is more then Fact Table data. I have some doubts....pls clarify me.
My system is BW 3.5
1.How can I find my Dimension table is having more then Fact table data?. I have 7 to 8 dimensions in Cube, so how can I find which diemnsion is having the more data?.
2. How can re model the cube?. Cube is haing 5 months Data. Without losing data how can I chage the Model?
3.I know one Program SAP_INFOCUBE_DESIGNS is there an dit will give the information, how can I use it?.
Thanks
Ganga

Hi Arun, Thanks
I searched based on the word "how to document on multi dimensional modeling on SAP BI".
I got lot of thing....
https://www.sdn.sap.com/irj/scn/advancedsearch?query=howtodocumentonmultidimensionalmodelingonSAPBI&cat=sdn_all
I hope the below one is correct?.
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/6ce7b0a4-0b01-0010-52ac-a6e813c35a84
Can pls guide me.
Arun I'm using BW 3.5.
Thanks
Ganga.

3 confirmed Dimensions and 2 fact tables

Hi experts,
how can we connect 3 confirmed Dimensions and 2 fact tables without loops and traps please give me a solution

Hi,
Dimensions Tables : Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:
    Customer_key
    Customer_full_name
    Customer_city
    Customer_state
    Customer_country
Fact Tables :a fact table consists of the measurements, metrics or facts of a business process. It is often located at the centre of a star schema or a snowflake schema, surrounded by dimension tables.
Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of an educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.
Context Versus Alias Overview :
http://www.dagira.com/2009/07/22/context-versus-alias-overview/
How to create context :
http://www.bidw.org/business-objects/universe-design/understanding-context-and-its-use-in-business-objects-universe/
You can also look on the eFashion universe for more information.
Thanks,
Amit

#datasync error - could that come from merging on fields from fact tables instead of dimensions tables?

I'm reporting out of two universes published by Epic
1. Warehouse - Patient
2. Warehouse - Transactions
I wanted to join two queries based on the primary key for a hospital encounter. Following the tutorial seemed pretty straightforward until I got to displaying data from a merged query.
The table displayed results from Query1, but adding fields from Query2 wiped out all the data in the table, leaving only #datasync in each field.
My workaround to get fields from both queries displayed (see screenshot)
1. Merge queries on *two* fields - primary key of hospital encounter and primary key of patient
2. Create new variable
3. Make variable type Detail
4. Associate variable with hospital encounter key from Query1
5. Set formula equal to a field from Query2
I'm not sure why this workaround works or if what I'm experiencing is a symptom of something larger. Could this workaround be needed because I am merging on fields from a fact table instead of fields from a dimension table?
Thanks in advance

You have defined merged dimension on 'company code-Key' which is common in both the Bex-queries.
You are able to bring the merged dimension and other objects from Query_ One to report block without any issue but when adding objects from Query_Two you are getting the error #DATASYNC.
In this case objects from Query_One are got sync with the merged dimension object without any issue because they got added first to it.
Similarly when you add merged dimension and objects from Query_Two you find no issue, because objects from Query_Two go sync first.
Once objects from a query(Query_One/Query_Two) got added to a merged dimension, when we try adding objects from other query we get #DATASYNC error. This is because data in the other query is not able to sync with the initial result set, this is a know behavior.
There are two workarounds:
1) Merging all common dimension/characteristic objects: Only merged dimensions data will sync with the initial query, un-merged dimensions/characteristic objects will still give #DATASYNC error.
2) Create detail objects/attribute objects at report level for all uncommon characteristic/dimension objects from query_two referring to merged dimension. Then add these newly created detail/attribute objects to the table block that is having initial query objects with merged dimension, with this you see result set of query_two in the table block not #DATASYNC error.
~ Manoj

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.2

At 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

Steps to create Universe without using Fact Table

Dear All,
i am confronting with a problem by creating an Universe.
The problem is that we do no have any fact table.
Could you please explain the steps for creating an universe without fatc table?
Thanks
Pat

The first thing to do is identify the tables in your schema that contain measures. These will be your base tables for contexts.
Then identify all the tables that relate to each of your candidate fact tables.
You may identify two related tables, both with facts in, which would give you a fan trap.
Say you have a schema with only three tables and they are related as: T1 -< T2 -< T3
T2 and T3 both have measure columns.
What you would need to do is create an alias of T2 (AT2) and join it to T2.
You would then have two contexts, T1-< T2 , T2-< T3 and T1-<T2, T2- AT2
For objects from T2, derive the dimensions from T2 and the measures from AT2.
Beyond that, it's fairly standard.
If you have a data schema it is going to be much easier for you.

Fact Tables without Dimension Tables.

Similar Messages

Maybe you are looking for