Understanding Star Schema Operations

Hi All,
I worked on Oracle Answers and have knowledge on Data Warehousing concepts. I have enough oracle documentation on OLAP, OBIEE, Data Warehousing.
But i 'm not able to understand the star schema concepts in and out. I'm lost on all documents, where i'm getting the simple answer on the following topics:
1. Is it necessary to create dimensions using CREATE DIMENTION or it can be a simple relational table structure with CREATE TABLE statement?
2. What will be the steps to create a very basic/simple star schema using DML statements not using any tool?
3. Where I can get very basic level step by step tutorial to create a very simple star schema by sql -> loading test data by sql commands -> then what queries we can use to get BI reports or using OBIEE to create a simple rpd.
Please give me some idea on this as I have to create a small OBIEE repository where i have to do create the warehouse and ETL process, everything.
Pls advise.
Thanks in Advance.
Sudipta

No my question was on creating the star schema. If i have to create a very simple star schema then can I create the star schema with the following relational tables?
create table dim_products (
product_id number primary key,
product_name varchar2(32),
brand varchar2(32),
category_name varchar(32),
sub_category_name varchar2(32)
create table dim_time (
time_id number primary key,
selling_date date,
selling_day number(2),
selling_month varchar2(12),
selling_Quarter varchar2(6),
year number(4)
create table dim_region (
region_id number primary key,
store_name varchar2(32),
city_name varchar2(32),
state_name varchar2(32),
country_name varchar2(32),
region_name varchar2(32)
create table fact_sales (
sale_id number primary key,
region_id number ,
time_id number ,
product_id number ,
unit_sold number,
constraint fact_sales1 foreign key (region_id) references dim_region (region_id),
constraint fact_sales2 foreign key (time_id) references dim_time (time_id),
constraint fact_sales3 foreign key (product_id) references dim_products (product_id)
Or I have to create the DIMENSIONS explicitly, in order to building the hierarchy levels?
Regards
Sudipta

Similar Messages

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.

What is star schema - pls explain with example

Hai.
what is star schema - pls explain with example
thanks in advance
Giri

Hi Giri,
SAP's BIW employs extended star schama
The extended star schema consists of a fact table (in two parts, E and F - f is the inbound table, E long-term storage). Dimension tables are connected to the fact tables via the DIMID(dimension id) which is a generated value and is stored in both dimension and fact tables. In addition, the dimension tables are connected to tables which hold master data values (or bind the dimension table to tables that hold the values), such as S tables, P, Q, X, Y. These dimension tables hold SIDs, again generated keys which relate values in the dimension table (the DIMIDs) with master data values. Thus, at the time of the query, join operations ensure that the master data values can be merged with the key figure values stored in the fact tables.
Truthfully, one does not need to understand this schema extensively in order to model in BI in SAP NetWeaver. It helps to understand master data, navigational attributes, etc. Otherwise, simply model the key figures in the fact table and the characteristics into dimensions and you're good - the application generates the star schema for you - you don't have to specify it.
See the transaction "LISTSCHEMA" which will show you the relationship between the F fact table and the other tables of the cube's star schema.
Also follow the link for more info:
http://help.sap.com/saphelp_nw04/helpdata/en/4c/89dc37c7f2d67ae10000009b38f889/content.htm
Thanks for any points you assign.
Regards

Why do we need SSIS and star schema of Data Warehouse?

If SSAS in MOLAP mode stores data, what is the application of SSIS and why do we need a Data Warehouse and the ETL process of SSIS?
I have a SQL Server OLTP database. I am using SSIS to transfer my SQL Server data from OLTP database to a Data Warehouse database that contains fact and dimension tables.
After that I want to create cubes using SSAS form Data Warehouse data.
I know that MOLAP stores data. Do I need any Data warehouse with Fact and Dimension tables?
Is not it better to avoid creating Data warehouse and create cubes directly from OLTP database?

Another thing to note is data stored in transactional system may not always be in end user consumable format for ex. we may use bit fields/flags to represent some details in OLTP as storage required ius minimum but presenting them as is would not make any
sense to user as they would not know what each bit value represents. In such cases we apply some transformations and convert data into useful information for users to understand. This is also in the warehouse so that information in warehouse can directly be
used for reporting. Also in many cases the report will merge data from multiple source systems so merging it on the fly in report would be tedious and would have hit on report server. In comparison bringing them onto common layer (warehouse) and prebuilding
aggregates would be benefitial for the report performance.
I think (not sure) we join tables in SSAS queries and calculate aggregations in it.
I think SSAS stores these values and joined tables and we do not need to evaluates those values again and this behavior is like a Data Warehouse.
Is not it?
So if I do not need historical data, Can I avoid creating Data Warehouse?
On the backend SSAS uses queries only to extract the data
B/w I was not explaining on SSAS. I was explaining on what happens inside datawarehouse which is a relational database by itself. SSAS is used to built cube (OLAP structures) on top of datawarehouse. star schema is easier for defining relationships
and buidling aggregations inside SSAS as its simple and requires minimal lookups to be performed. Also data would be held at lowest granularity level which can easily be aggregated to required levels inside OLAP cubes. Cube processing is very resource
intensive and using OLTP system would really have a huge impact on processing performance as its nnot denormalized and also doing tranformation etc on the fly adds up to complexity. Precreating a layer (data warehouse) having data in required format would
make cube processing easier and simpler as it has to just cross join tables and aggregate data based on relationships defined and level needed inside the cube.
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Star schema design

Hi,
I know that in classical star schema the dimension tables sits within the info cube and so we cannot use this dimension table in any other cube we need to have separate dimension table for that cube thought it might be having same data. I also know to over come this redundancy extended star schema came into picture where we have SID table and we keep the dimension table out of the cube and reuse the dimension tables across many cubes.
Now what i don't understand is that instead of having Separate SID tables for linking the dimension and fact tables why cant we make the DIMENSION table generic and keep them out of the infocube so that we can same the same dimension table for many infocube in this case we wont need SID tables.
suppose i have one info cube which has dimension vendor material and customer and its keyfigure is quantity and price and i have a separate infocube which has dimesnion material customer and location and its key figure is something else ......so here in why cant i keep the dimensions out of the infocube and use the dimension material customer for both infocube.

Your dimension tables are filled based on your transaction data - which is why dimension table design is very important you decide to group related data for the incoming transaction data into your dimension tables .
The dimension tables have SIDs which in turn point to master data = in the classic star schema - the dimension tables are outside the cube but the dim tables have the master data within them whhich is overcome using the extended star schema.
The reason why dimension tables can be reused is that the dim IDs and SIDs in the simension table correspond to the transaction data in the cube - and unless the dim IDs in both your cubes match you cannot reuse the dim tables - which means that you have exactly the same data in both the cubes - which means you need not have two cubes with the same data.
Example :
Cube 1 : Fact Table
Dim1ID | DIM2ID | KF1
1|01|100
2|02|200
Dimension Table : Dim 1 ( Assumin that there are 2 characteristics in this dimension ) - here the DIM1ID is Key
Dim1ID | SID1 | SID2
1|20|25
2|30|35
Dimension Table Dim 2 - Here the Dim2ID field is key
Dim2ID| SID1 | SID2| SID3
01| 30| 45
02|45|40
Here the Dim IDs for the cube Fact table are generated at the time of load and this is generated from the NRIV Table ( read material on Number Ranges ) - this meanns that you cannot control DIM ID generation across cubes which means that you cannot reuse Dimension Tables

HR Analytics Star Schema Definitions

All--
We currently report on PeopleSoft data by extracting it into a data mart. ( The data store's configuration is not in a star schema format). We use it for day to day operational reporting needs. We are researching on HR Analytics and want to know more details about the data elements covered in the schemas, is there any document that explains the details of the various star schemas and the mappings to the original PeopleSoft database elements ?
We need this to perform a gap analysis. Any help would be much appreciated.
Thanks,
Ajit

Apparently on eDelivery they have finally made available the Source to Staging Mappings in spreadsheet form.
Check that out.
Bob Murching posted about it a few cycles ago on this forum as well.
To clarify the document does not exactly detail the stars. You need to download the Data Model Reference Guide from Metalink3 to see those details.

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

Need help with an extended star schema.

I have the following data in spreadsheet form and I need to transpose this into an extended star schema in order to prdouce my characteristics and key figures, however I'm having a little trouble understanding where to include the Product Group in the star schema and also what to do with the Sales Doc (Invoice Number) in the sales information spreadsheet.
I need to summarise the data into the following also:
1.     Total quantity and revenue for each Channel and product group
2.     Total quantity and revenue for each Channel and product group (July 2009 to September 2009)
3.      Total Quantity and Revenue for iphone sales
So my question in short is what would the star schema look like? I'm hoping somebody can help me over this hurdle.
The following are the details from the spreadsheet:
Product Details (Attributes)
File Name: Product_Details.csv
Structure     FieldName     Length     Description
     ProdID     5     Uniquely identifies a product
     PG_Group     20     Identifies products in specific groups (Navigational field)
Sample Data
ProdID,PG_Group
PDS01,COMPUTER
PDS02,COMPUTER
PDS03,COMPUTER
PDS04,ACCESSORIES
PDS05,ACCESSORIES
PDS06,ACCESSORIES
PDS07,ACCESSORIES
PDS08,HARDWARE
Product Description (Text)
File Name: Product.csv
Structure     FieldName     Length     Description
     ProdID     5     Uniquely identifies a product
     Prod_Desc     Medium Text     Represents the product description
(Navigational field)
     Language     2     Represents the language descriptor
Sample Data
ProdID,Prod_Desc,Language
PDS01,Notebook Speedy I,EN
PDS02,Notebook Speedy II,EN
PDS03,PC Thinkbox I,EN
PDS04,USB Adaptor,EN
PDS05,iPhones PX2,EN
PDS06, Stereo Kit,EN
PDS07,Camera Connector,EN
PDS08,USB Storage,EN
Transactional Data
Sales information
File Name: Sales.txt
Structure     FieldName     Length     Description
     Product     5     Uniquely identifies a product
     Sales Doc     4     Sales Document number (Invoice Number)
     Calendar Year     8     YYYYMMDD format
     Channel     1     Represents the distribution channel the product was sold by
     Quantity     4     Numeric value indicating the number of each product sold on a specific sales document
     Unit     2     Refers the unit specified by the quantity
     Revenue     8     Refers the sales amount of a specific product on a specific sales document
     Currency     3     Relates the revenue currency type
Sample Data
Product;Sales Doc ,Calendar Day,Channel,Quantity,Unit;Revenue,Currency
ZD_PROD,0DOC_NUMBER,0CALDAY,ZD_CHAN,ZD_QTY,0UNIT,ZD_REV,0CURRENCY
PDS07,7389,20090705,A,95,EA,151905,USD
PDS08,7389,20090705,A,115,EA,264385,USD
PDS02,7473,20090706,B,55,EA,3580445,USD
PDS01,7472,20090706,C,110,EA,604989,USD
PDS02,7472,20090706,C,43,EA,2799257,USD
PDS03,7472,20090706,C,75,EA,4507425,USD
PDS04,7472,20090706,A,339,EA,301032,USD
PDS06,7472,20090706,A,120,EA,47976,USD
PDS01,7473,20090718,D,55,EA,3024945,USD
PDS02,6845,20090806,B,30,EA,195297,USD
PDS07,6877,20090807,C,800,EA,12792,USD
PDS08,6877,20090807,C,250,EA,57475,USD
PDS03,6912,20090812,C,250,EA,1502475,USD
PDS04,6900,20090812,B,70,EA,6216,USD
PDS01,6899,20090812,C,12,EA,659988,USD
PDS04,6899,20090812,D,55,EA,4884,USD
PDS04,7479,20090815,C,80,EA,7104,USD
PDS05,7479,20090815,C,300,EA,70497,USD
PDS05,6809,20090818,A,1000,EA,234990,USD
PDS06,6809,20090818,A,130,EA,51974,USD
PDS03,6831,20090822,C,15,EA,901485,USD
PDS04,6831,20090822,C,500,EA,4440,USD
PDS03,6830,20090822,C,125,EA,7512375,USD
PDS06,6830,20090822,C,400,EA,15992,USD
PDS04,6841,20090825,C,53,EA,47064,USD
PDS05,6841,20090825,C,350,EA,822465,USD
Distribution Channel
Channel (text)
File Name: Channel.csv
Structure     FieldName     Length     Description
     ChanID     1     Uniquely identifies a specific distribution channel
     Chan_Desc     Medium
Text     Full name of each distribution channel
(Navigational field)
Sample Data
ChanID, Chan_Desc
A,Phone
B,Fax
C,Internet
D,Other
Star Schema Model:

Potentially the issue may be the combination of actual distance and the presence of any Wi-Fi interference at the location of the AirPort Express that may be the culprit here. The bottom line is you would want the Express to be within a 25+ dB range of the Extreme to be sure that it can consistently stay connected to it.
For more details on proper base station placement, check out the following AirPort User tip. Please post back your results.

EIS and setup of Star Schema

I want to be able to drill back into our ERP system from Essbase using EIS. It is my understanding that I need to create a Star Schema in order to get EIS to function properly. Is this correct?Another question is when I create the Dimension tables for the Star Schema, is a Parent Child Relationship sufficent or do I need to create a column for each level/generation in the dimension? Do I need this for Dimension build or Drill back reports?Thanks in advance.

EIS does require a star schema. You can find out additional information in the Essbase.com White Papers section - there's a white paper there that should address your questions about tables:http://www.essbase.com/main.asp?webpagekey=428Regards,Kimberley Kent

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

Snowflake/Star Schema in OBIEE

Hi Gurus,
I would be very glad if you can help me to resolve this problem.
Before posting, I searched the forum there are similar queries(Circular Join) but I do not get the solution.
I have fact and dimension tables builded with star schema which I do not have any problem. But there is a fact table which has dimension to dimension relation between them.
When I tried to connect them which I explained in below I am getting error(Circular join problem) or If I fix the error, In Obiee analysis I am getting another error which says there is no fact table between tables. Let me explain the situation;
I have 4 dimensions table and a fact table;
connection between them;
Sales Dim(1) ---> Fact.A(N)
Date Dim(1) ---> Fact.A(N)
Customer Dim(1) ---->Fact.A(N)
Sales Channels Dim(1) --->Sales Dim(N)
Date Dim(1)---> Sales Dim(N)
Date Dim(1) ---->SalesChannel(N)
I can see that there are bunch of circular join in here :(. I did not understand to use Alias to resolve this problem.
For instance; Dim A--->Fact AC
Dim B --->Fact AC
Dim A---> Dim B
If I create a Alias for Dim A, I can resolve the problem but which of them should I drag to Presentation Layer(at the end both of them same but Dim A used by other fact tables too). If I drag to Dim A nothing will be change or I am totally lost:(
If you do not understand the question I will try to be more clear.
I would be very happy if you can help me.
Thanks in advance.
M.S

Hi M.S,
If I got your issue correctly, then the issue is the join between the 'Date Dim' -> 'Sales Dim' and 'Date Dim' -> 'Channels Dim'. I was just trying to understand the model here, and thinking why do you need a join between these dimensions.
Anyway, a report with Sales and Date dimension can always be resolved through the Fact table. However, if you still want all combinations across this dimension, you can still use a implicit column methodology for this issue. you might want to refer to venkat's blog on this approach here.http://www.rittmanmead.com/2009/08/oracle-bi-ee-10-1-3-4-1-reporting-on-non-transactional-dimension-values-equivalence-of-outer-joins/
Hope this helps.
Thank you,
Dhar

Strange star schema created by tutorial

Hi, I have a fresh and clean installation of BI SE1.
I followed the steps for the tutorial (those related to OWB and created the data mart).
I really don't understand what kind of star schema is the resulting one and I think there might be a bug in OWB.
In "Sales" table there are no rows referencing those records in dimensions which have negative dimension keys. So why generating those rows in dimensions? They are useless...

I understand that...But
1) don't you think that, if you do not generate an aggregate sales table, it would have been better to use a table in OWB for dimension tables and not dimensions, so that those useless (useless if you do not generate an aggregate sales table) rows wouldn't have been generated?
2) the Channels dimension in BISE1_SALESWH is not correct, in fact it is different from that in BISE1_TUTORIALWH.
Regards

Star Schema and Oracle 11gR2 ?

Star Schema and Oracle 11gR2 ?
I know the star schema (ROLAP) and implemented couple of them. Apart from general design principle of dimension, FACT, surrogate key etc, what are the specific items needed in Oracle 11gR2?
Some one talked about over 10 conditions/pre-requisits for Star Schema (ROLAP) implementations in Oracle 11gR2. I did some search, but I did not get any hits.
Do we design Star schema (ROLAP) differently in Oracle 11gR2?
Any pointer welcome.
Thanks in helping.

Hi,
from my experience there are no specific requirements for the star schema design when using owb 11.2.
When using the OWB ETL Option (extra license required), one may use the owb dimensions and cubes.
These make mapping development easier, since support for SCD2 is built into the dimension operators. Loading the cube is simplified because the lookup of the surrogate key from the dimension is built into the cube operator.
These owb objects will deploy specific dimension and fact tables. If you already have existing ones, you must modify them manually.
I implemented several projects without these advanced features. Baiscally I did the same in OWB what I would have done using hand-coded SQL and PL/SQL. And it worked just fine.
If you find those 10 conditions, please post them here. I'm curious to learn about them!
Regards,
Carsten.

Master data sharing using ext. star schema

Hi,
I have undetrstood the concept of extended star schema.
I understand,
One of the advantages of extended star schema is, that the master data can be shared, meaning, since the master data is stored separately, other star schema's can also share this master data provided it is of the same relevance( with same infoobjects used in this star schema).
Confirm if my understanding is right and if right,
Any idea or suggestion how to demonstrate this ?
Points will be given for good answers.
thanks.
bwlearner

Hey,
If u could map this with programming.
MASTER DATA Tables are like GLOBAL declaration and InfoCubes (Fact Tables) are like LOCAL declaration. Any number of IncoCubes can access one particular Master Data Table.
Assume Sales data coming from 5 regions. Here 0CUSTOMER & its attributes will update the same Master Data Table. The data fields will be stored in the Infocube. So all the 5 InfoCubes access the same Master Data tables using the Dimension & SID tables.
Clear ?
Best Regards....
Sankar Kumar
+91 98403 47141

Star schema in Physical Layer

Recently, i came across a question from one of colleague. The discussion went as follows:
He asked me what is star schema and where can you define it? Physical layer or BMM layer?
I explained about star schema and answered his rest of the doubt that, we define it in BMM layer.
His immediate question is why can't we define it in Physical layer? Since BMM layer allows to build dimensional models, so, we have to build it in that layer itself is my reply. But, later in the evening, when i started thinking on my way to home, i started thinking about his doubt.
Here, what am curious to know is since we can join tables in Physical layer too, why can't we define star in Physical layer? and why only in BMM? and what are the difference in the Joins that we made in Physical layer to that of BMM layer?
I tired getting answers for these in documents and in some other online resources, but, am not succeed. So, am approaching this forum in anticipation. Can anyof you help us understanding these concepts better.

In OBIEE Server Administration Guide it is written for logical fk join:
Logical foreign key joins might be needed if the Oracle BI Server is to be used as an ODBC data
source for certain third-party query and reporting tools. Typically, you should not create logical
foreign keys. This capability is in the Administration Tool to provide compatibility with previous
releases.
And logical complex join:
The use of logical complex joins is recommended over logical key and foreign key joins.
And physical complex join:
In the physical layer of the repository, complex joins are joins over nonforeign key and primary key
columns. When you create a complex join in the physical layer, you can specify expressions and the
specific columns on which to create the join. When you create a complex join in the business model
layer, you do not specify expressions.
I agree, that always are some special cases, but in general it should be clear when to use which joins.
So, you should read chapters 4,5 one more time this administration guide [OBIEE server administration guide|http://download.oracle.com/docs/cd/E10415_01/doc/bi.1013/b31770.pdf]

Understanding Star Schema Operations

Similar Messages

Maybe you are looking for