Star schema question

Hi,
I have a question about the realization of the star schema. I have familiarized me with the basic concepts of dimensions and fact tables. But what I don’t get is how I “combine” the dimensions with the fact table. I know that the fact table includes the dimension-IDs and measures. But do I use the joiner-operator in the OWB to join the dimension-ID (IDs of the dims are the criteria for the joiner condition) to create the fact table?
So my understanding is when I have for example 3 dimensions (product dimension, sales dimension, time dimension) and one fact table.
The realization looks like this:
product dim ->
sales dim -> joiner operator = fact table with the IDs of the dims and measure
time dim ->
Please correct me if I am wrong.
If there is something that I can read to this subject of matter it would be very nice if someone could post it.
Thx

Hi,
first you load the dimensions. Every entry has an id (surrogate key) and some business key (coming from the data source).
When you load the fact, you use the business key from the data source to join (using a joiner or lookup operator) the dimension and get the id (surrogate key) from it. You only load the id and the measures into the fact table.
Make sure to handle the case that the business key is null or no entry in the dimension can be found.
If you query the fact table you must always join the dimensions.
Regards,
Carsten.

Similar Messages

Newbie question : why is star schema fast and efficient?

Hi all,
just a stupid question, but I haven't been able to find a proper
answer so far...
Why is star schema a good design for Data Marts and DWH?
What is the underlying reason that makes it attractive
performance wise?
Why wouldn't just one big table with all the data in it and with
the proper indexes be enough?
Thanks all!!
Regards
Vincent

There are several reasons to use star schemas, particularly in
Oracle.
A flat table like you asked about looks attractive but has
several flaws, i.e. massive data redundancy, no logical
groupings, no aggregation (or additional redundant data
aggregated), etc.
A start schema is semi-denormalized to allow easy reporting. A
truely normalized system is diffucult to report against be cause
you may have to join many tables to return just 2 pieces of
related data. A star schema enables you to join to only a single
dimension table to the fact table to return the same 2 pieces of
data. If you're returning many pieces of data, a star schema
keeps access very simple. Most third party reporting tools
recognize star schemas and will build your where clauses behind
the scenes making them a lot more useful to end users.
Oracle is adding optimizations to the cbo for start schemas.
Using dimensions, materialized views, partitions, IOTs, etc
greatly enhances performance for queries against massive amounts
of data. It does make loading the data more difficult but the
trade off at query time is worth it.
A flat table structure, besides having a lot of redundant data,
is hard to optimize. When you have terebytes of data, a flat
table structure gets scary even with indexes.
This is just my opinion, hope that helps.
Lewis

Question on BW Star Schema

Hello all
Please help me understand the DIM/SID table concept.
I was going through the BW star schema and I was curious to know the importance of Dimension table. What is wrong with putting the SID ID directly in Fact table instead of relating it through the DIM table?
Please post a link to documentation on SAP Star Schema, if you have.
This is how I understood
Fact Table:
DIM_CUST     | QUANTITY
001          | 50
002          | 100
001          | 60
Dimension Table:
DIM_CUST     | SID_CUST
001          | 011
002          | 022
003          | 033
SID Table:
SID_CUST     | CUST_ID
011          | 123ABC
022          | 767TYT
033          | 989UHY
- In Fact table we identify unique transaction by combination of Cust ID and Date/time
- We can have the same Cust ID appearing multiple times in Fact table for different transactions
- DIM and SID table have 1:1 relation
- In SID table, SID ID has 1:1 relation with a customer ID
If they are all right, I still want to know why can't we have SID ID appear directly in Fact table?
Please explain.
Thanks
-Sudhakar
Message was edited by: Sudhakar Upadhyaya
Message was edited by: Sudhakar Upadhyaya

About you last question:
"Can anyone give me a scenario where we use multiple characteristic in the same domension?"
The first consideration about the number of characteristic involved is the most evident, but consider even the problem related with the number of key fields of a DB Table (no more than 16).
Speaking about a scenario: let's say you have to report on Division, Sales Org, Sales Off, and Sales Pers: putting all this char in a "line item" dimension makes sense only in order to elimiate the corresponding Dimesion Table, but are you sure that the query will be faster that putting all of the in the same Dimension? And what about the comprehension of the underlying schema? Think about a complex one, with 50 or more Chars ...
By the way the easier way to solve such a doubts is to read something about MultiDimensional Data Modeling: there's a wide litterature about this topic that can't be summarized in few rows without omitting important notes
If you don't want to start with "heavy" books search in http://service.sap.com/bw for a doc about Multidimensional Data Modeling (see under InfoIndex / DataModeling / BW ASAP for 2.0B Phase 2: Multi Dimensional Data modeling (doc)) that's an old doc (before 2k), but a very good starting point, that will answer to you questons about SidID and DimID.
Hope it helps
GFV

Star Schema/Cube Question

I am fairly new to OLAP and cubes, yet have the task of creating one from a star schema.
The schema has 2 fact tables, instead of most examples I see online with 1 fact table. Should this be 2 cubes? Can it be 1? Any information could prove helpful...thanks!

Assuming the fact tables have related dimensions, then I would recommend one Analytic Workspace with multiple cubes inside that AW. That would allow them to share one or more dimensions. There is an example of this in the Oracle By Example lesson: http://www.oracle.com/technology/obe/obe10gdb/bidw/awm/awm.htm
I am fairly new to OLAP and cubes, yet have the task
of creating one from a star schema.
The schema has 2 fact tables, instead of most
examples I see online with 1 fact table. Should this
be 2 cubes? Can it be 1? Any information could
prove helpful...thanks!

Star schema without a fact table?

Hi,
I'm preparing my warehouse for using with Discoverer and my question is about the star schema.
- Is a star schema directly associated with data warehouse?
- Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?
The problem is, I'm thinking of usine Discoverer but should I use it if it's not connected to a data warehouse?
As I told, I'd like to modelized my data "like" a star schema but my "center table" will contain only the foreign key of my dimensions; no time dimensions, no aggregate data in the center table (fact table).
Is there another word for the model I'd like to do?
Thank in advance.

Hi,
Is a star schema directly associated with data warehouse?Not really, a star schema is just one where there is one large fact table joined to many smaller dimension tables using key fields. You usually see this in data warehouses.
Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?A star schema must have a fact table but it doesn't need contain summarised values or a time dimension.
You can use Discoverer with any Oracle database, it doesn't have to be a data warehouse.
Rod West

Regarding Extended star schema

Hi Friends,
In Extended star schema,master data will load separately ,which will connect through sid's to dimension table .
My question is.. This master data tables can be used other than this cube ?
Please tell me i am in confusion.
Thanks in advace,
Regards,
ramnaresh.

Hi
InfoCubes are made up of a number of InfoObjects. All InfoObjects (characteristics and key figures) are available independent of the InfoCube. Characteristics refer to master data with their attributes and text descriptions.
An InfoCube consists of several InfoObjects and is structured according to the star schema. This means there is a (large) fact table that contains the key figures for the InfoCube, as well as several (smaller) dimension tables which surround it. The characteristics of the InfoCube are stored in these dimensions.
An InfoCube fact table only contains key figures, in contrast to a DataStore object, whose data part can also contain characteristics. The characteristics of an InfoCube are stored in its dimensions.
The dimensions and the fact table are linked to one another using abstract identification numbers (dimension IDs) which are contained in the key part of the particular database table. As a result, the key figures of the InfoCube relate to the characteristics of the dimension. The characteristics determine the granularity (the degree of detail) at which the key figures are stored in the InfoCube.
Characteristics that logically belong together (for example, district and area belong to the regional dimension) are grouped together in a dimension. By adhering to this design criterion, dimensions are to a large extent independent of each other, and dimension tables remain small with regards to data volume. This is beneficial in terms of performance. This InfoCube structure is optimized for data analysis.
The fact table and dimension tables are both relational database tables.
Characteristics refer to the master data with their attributes and text descriptions. All InfoObjects (characteristics with their master data as well as key figures) are available for all InfoCubes, unlike dimensions, which represent the specific organizational form of characteristics in one InfoCube.
Integration
You can create aggregates to access data quickly. Here, the InfoCube data is stored redundantly and in an aggregated form.
You can either use an InfoCube directly as an InfoProvider for analysis and reporting, or use it with other InfoProviders as the basis of a MultiProvider or InfoSet.
See also:
Checking the Data Loaded in the InfoCube
If the above info is useful, please grant me points

Star schema versus snowflake schema

I have a question regarding dimensional data modeling. My question here is, when star schema model would be useful and when snowflake schema model would be useful.
In star schema, we have only fact and it is connected with dimensions. But in snowflake schema, we are normalizing dimension into one more level. Let us say, we have dimension product. Product can be normalized into another table called supplier. Let us take another example, customer dimension. Customer dimension can be normalized into country…
Advantage of star schema is, easy to write the query since we have only less tables. You do not need to join multiple tables when we write the query. It would improve the performance some time.
Advantage of snowflake schema is, it is little complex to write the query, since we have to join multiple tables. Performance might improve some time when we join smaller tables…
My question is, at what circumstances, we can use star and snowflake schema? I am not able to define the word sometime_
Any help is highly appreciated…

Hi,
There is a trade off on the availability and the Complex analytics.
A star schema is good if you have the functional requirements really simple. Like the dimension is not SCD Type2 (slowly changing dimension) and you don't need to do "AS IS" vs "AS WAS" reporting.
In modern Analytics in any domain dimensions are SCD Type 2 as business keep on evolving. In a star schema structure this will cause explosion of data if there are frequent changes at the higher levels of the dimensional hierarchy. That anyway will hit the performance.
As far as my experience goes, at the data model level it is better to have snow flaked dimensions. and while managing the metadata (in a BI reporting tool) you can consolidate the snowflaked dimensions in star schema structures. That will make ah hoc analytics much simple for the business users.
A lot of performance measure can be taken to improve the end user experience.
In short the trend in BI analytics demands to have a snowflaked structure rather than a simple star schema structure.
Hope this helps.

Star Schema tables Creation

If I am creating a BI analytical application from sample Sales Hisotory schema's transactional data, what is the first Step I need to do? Should I create a star schema from the transactional tables? If this is correct, What I tool I need to use to create such tables with data? I believe once this is done I can create dimensions , measures and cubes using OWM11g. Some on please help me. I am very very new to OLAP , But has lots of interest in it
Thanks
George

Hi George,
If you are working with 11g - did you install all the latest patches? I strongly recommend applying all available patches when working with 11g. All the information you need is here - http://www.oracle.com/technology/products/bi/olap/collateral/olap_certification.html
As for your question about the criteria for desgining dimension tables, the best advice I can offer is to work with star or snowflake dimensions. You can also see sample schema designs for both at these links
Also, in case you haven't already seen it, there is a good blog posting on working with different kinds of dimensions/hierarchies here - http://oracleolap.blogspot.com/2008/01/olap-workshop-4-managing-different.html
Finally, you might find this [white paper|http://www.oracle.com/technology/products/warehouse/pdf/Benefits%20of%20a%20multi-dimensional%20model.pdf] useful as you say you are new to OLAP
Let me know how you get on
Thanks,
Stuart Bunby
OLAP Blog: http://oracleOLAP.blogspot.com
OLAP Wiki: http://wiki.oracle.com/page/Oracle+OLAP+Option
OLAP on OTN: http://www.oracle.com/technology/products/bi/olap/index.html
DW on OTN : http://www.oracle.com/technology/products/bi/db/11g/index.html

BMM layer creation (Star Schema Physical Layer) - What to add/not add?

Hi All,
I am just looking for any general feedback on the thought/question below.
I am setting out on creating my first BMM layer and trying to determine what I need to do in this layer that will be different and add value from what I already did in the physical layer. My data model is already defined as a star schema within my data mart source. So in the physical layer I have my facts imported along with the dimensions and I have joined them together as needed. Here is what I think I will setup as I move into the BMM layer:
1. I will add heirarchies as needed to enable drill down within my reports
2. I will need to add my calculations/measures to allow for any type of metric to be returned through a request in Answers
3. I do not see a large need to create logical tables (at least not yet) based on multiple physical source tables as my source is already a star schema and dimensionally modeled. For users that also already source a star schema at the physical layer .. do you find that you do a lot of logical table creation/mapping to add functionality or does your BMM look a lot like you Physical Layer?
Other than steps 1 and 2, I am not really sure how much additional manipulation I might do from the Physical to BMM layer since my Physical is already a star schema. Am I missing anything? Obviously everyone's data model and circumstances are different but I wasn't sure if maybe there were some good thoughts on what I might be missing (if anything)?
One last question .. I am not currently planning to use any aliases at the Physical Layer but I do plan to rename the tables at the presentation layer to be more business verbage like. Why are others using aliases?
Thanks in advance for the help.
K

Alastair, thanks for the advice. I'll definitely keep that in mind as I start to build out the BMM.
One question/issue I just ran into as I was wrapping up my Physical Layer mapping. When I check for global consistency, I am getting an error that is complaining that I have multiple joins defined between the same two tables (which I do). This is because I have the following setup:
TBL_A_FACT
F_ID_HIT
F_HIT_DESC
F_ID_MISSED
F_MISSED_DESC
TBL_B_DIM
F_ID
F_DESC
Table A joins to Table B in two ways:
TBL_A_FACT.F_ID_HIT = TBL_B_DIM.F_ID
TBL_A._FACT.F_ID_MISSED = TBL_B_DIM.F_ID
The F_IDs can be either hit or missed on any given fact record and the total distinct set exist in the dimension.
When I define two foreign key joins in the physical layer based on the relationship above and check Global Consistency, I get an error saying that "TBL_A and TBL_B have multiple joins define. Delete duplicate foreign keys if they exist" and it is listed as an error. I guess this makes sense because when the two tables are used in a request OBIEE would need to know how to join them (using the hit or missed field). What is the best approach for handling this..
- Should I define TBL_A twice in the physical layer as:
TBL_A (Alias TBL_A_HIT)
F_ID_HIT
F_ID_HIT_DESC
TBL_A (Alias TBL_A_MISSED)
F_ID_MISSED
F_ID_MISSED_DESC
Or do something like the above in the BMM layer?
Thanks for the help!
K
And then establish the relationships using these separate tables?

Creation of star schema from snowflake schem in BMM layer

hi,
This is my situation.I have "Fact-table" which has Dim 1 .now Dim 1 is joined to Dim2,Dim3
Fact
|
Dim 1
|
| |
Dim 2 Dim 3
Now in Bmm Layer how can i make this snowfalke schema to star schema.I heard about making changes in the Logical Table source.And what will be the look of the presentation layer.
Any help is appricaited Guys.

In physical layer, you have a join between Dim 1 and Dim 2, Dim1 and DIm3, Fact and Dim1. In BMM for Dim1, in the sources, add Dim2 and Dim3. You may add both these dimensions in one single LTS if the data is not duplicate in the tables. In case the data is duplicated add them as seperate LTS in the sources for Dim1. Refer this post for reference -- Logical Table source source query
In BMM you need a join between Dim1 and Fact. Basically your Dim1 is sourced from three different tables which are your dimensions. This would transform your snowflake into star. In your presentation layer you will have all the columns from your dimensions (except for the duplicates, lets say you have column A in both dim1 and dim2, you should map this column in column mapping tab so as to enable BI server to pick the most economical source) and facts.
Hope this clears your question.

Star Schema and Cubes

Hi,
I'm learning the basic concept of data warehousing and I've some question in this regards.
1) I want to know, are we have to first create star schema and tables according to that star schema in dbms, from that star schema we have to built cubes OR we directly build cubes from extracted data through OLTP systems.
2) secondly, when we create cubes, in which formate they are store in dbms and are they directly load in the memory at run time?
Please clarify me in these concepts as new to data warehouse I've certain concept misunderstanding in this regards. Answers will be highly appreciated
Regards,
D.Abbasi

1) I want to know, are we have to first create star schema and tables according to that star schema in dbms, from that star schema we have to built cubes OR we directly build cubes from extracted data through OLTP systems. Star schema is the Dimensional Modeling Technique and that need to considered while creating Dimension and not cubes.
So you need to create first design your database either in Start schema or Snow flag and then need to create dimension tables and after wards Cubes.
2) secondly, when we create cubes, in which format they are store in dbms and are they directly load in the memory at run time?Cubes and Dimensions are stored in Database in some different format.
This is the nice article regarding how the data is store in DB,
http://www.dba-oracle.com/t_olap_dimensions_cubes.htm
Cheers
Nawneet
Edited by: Nawneet on Mar 29, 2010 5:47 AM
Edited by: Nawneet on Mar 29, 2010 5:50 AM

Star Schema and EUL

1. It's a prerequisite to use a star schema to build a EUL or I can/ must used a Relational Schema?
2. The OLAP Option of Discoverer Plus work with an EUL or with a star schema
3. Which components requiere the OLAP option that don't require the Relational Option (i.e. AW) ?
4 I can generate a star schema as: a) a simple relational model where the FK key is a common domain for the fact and dimension table (i.e. Dept. Number) and having a table for each dimension (I don't speaking about time dimensions, but fields like barnch, dept., etc,). b) a star schema where the dimensions are grouped in tables depending on its significance (i.e. Producto, Channels, Time, etc). In this case I'll use a auto-generated sequential number as key for each table record, wich is referenced in the fact table. The question is, which is, in general, the best strategy 1.a ot 1.b. It depends of the size of the database?
5. There is two bussines areas wich need the same information, but one of them, will used always a summarized version whit 60000 records (the other one will process more than 1000000 each time). No doubts in using two distincts set of tables to generate two distincts EULs or Star Schemas, in order to gain in performance?

This is a more suitable question for the Business Intelligence (EBS).
In the mean time, you may want to check the BI OBE: http://www.oracle.com/technology/obe/obe_bi/bi.html , as well as http://www.oracle.com/technology/products/bi/index.html, http://www.oracle.com/technology/documentation/bi_doc.html
~ Madrid.

Do we use direct star schema concept anywhere in sap bw

i know about extended star schema,and where sap uses this concept.
my question is do we use normal star schema concept any where in sap bw, apart from extended star schema concept.
if yes specify the answer briefly .
thanks in advance
with regards
yash.b

Hi,
If I'm not mistaken an Analytic view in Hana is more like the normal star schema, it is definitely not extended and can be consumed by BW for OLAP processing.
Regards,
Michael Devine

How to document your star-schemas and dashboards?

Hello practitioners,
We are new to OBIEE and started some weeks ago. We are a two-men team. One guy doing all the data design and the other for everything around Answers.
So it happens regularly that the other guy has to ask the one guy, about the exact definition and meaning of data-fields, he wants to use in Answers.
Being a real programmer the one guy only needs a proper, self-explainary field name as documentation, of course (or so he thought).
Question:
What tools and methods do you use to document the star-schemas and dashboards?
Being the other guy, it is important, that I pick the correct fields, while on the other hand I do not want to disect a dashboard I built a while back, everytime somebody wants something simular, just to figure out what I actually did, back then...
Thank you for your help
Turalf
Edited by: Turalf on Mar 24, 2010 12:03 PM

Hi Turalf,
Have you looked at the OBIEE Metadata Dictionary ? A method to allow answers users to gain access to column definitions, and you can view the mapping from Presentation, through BMM to Physical layer.
Im pretty sure you can expose comments from the RPD into this also.
http://obiee101.blogspot.com/2008/12/obiee-metadata-dictionary.html
Maybe you could look at the ODI - OBIEE data lineage also, it provides "report to source" mapping info :
http://www.oracle.com/technology/obe/fusion_middleware/ODI/OBI-ODI_Lineage/OBI-ODI_Lineage.htm
Hope this helps.

Star schema and Infoprovider

Hello,
maybe this question is strange but is it necessary to create for each Infoprovider / Infocube one star schema?
Thanks in advance

Hi
I t is imperative that you refer some documentation related to BI Modeling. There are a couple of good docs. available which explain in detail about building an Infocube based on star schema to meet certain reporting requirement.
From your statement, it is clear that you still need to get a better of understanding of the modeling. Instead refer to the link below. It's a fantastic document.
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/6ce7b0a4-0b01-0010-52ac-a6e813c35a84
Cheers
Umesh

Star schema question

Similar Messages

Maybe you are looking for