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

Similar Messages

Extended Star Schema

Hi
Right now I'm trying to implement SAP HR Infotypes into SAP BW. I try to combine 10 infotypes (all Personal Administration) into one infocube. The confusing one is that when I see my dimension, there something strange (please see below)
Dimension 1 (from PA0016)
ZDATEFROM16
ZDATETO16
ZXXX (60 character, don't have master date attribute or text)
ZYYY (30 character, don't have master date attribute or text)
ZAAA(3 character, only master data text)
Dimension 2 (from PA0023)
ZDATEFROM23
ZDATETO23
ZCCC (60 character, don't have master date attribute or text)
ZBBB (30 character, don't have master date attribute or text)
ZDDD (20 character, don't have master date attribute or text)
If i see my dimension, it seems strange because most of them don't have master data (text,attr,hierarchy).
Is this violate the extended star schema design? Thank you.
Regards,
Satria

You can use characteristics such as ZXXX without master data (text, attr, hier) in extended star schema. It is not a violation. This means in business, for this characteristic you really don't need its text, attribute or hierarchy.
When perform data modeling for you HR cube, please do consider the design, can some characteristic be attribute of another one? Will you use hierarchy such organization level for some characteristic? characteristic with text, attribute or hierachy can provide more flexibility in reporting.

Why was the extended star schema scrapped?

Hi,
BW on HANA takes out the dimension tables and gives us back the original star schema structure.
Now my questions are
- How did the original extended star schema help the old BW on oracle or DB2 systems? I mean what was the need for such a design
- If it offered some kind of optimization .. then why was it scrapped in BW on HANA? Couldn't it have added on to the performance that HANA DB brought?
Regards,
Sam

Can anyone please explain.. ? Krishna Tangudu Thomas Jung Shyam Uthaman .. Any thoughts?

Extended Star Schema doubt

Hi ALL,
Fact table --- Dimension table -
Sid Table -- master data values.
Fact table:
Contains Key Figures and Dimensional id's
Dimension table:
Contains Dim Id & SID
SID table:
SID and Master object ID ( eg: Customer ID)
Master Data Table:
contains Customer Attributes , Texts , Hierarchies for that Customer ID.
THis is the Extended Star Schema design.
MY DOUBT:
1)In Dimension table itself if we place that Customer ID(No SID table next) what will happen?
Fact table --> Dimension table --> Master data Table
2)Instead of that SID table we can directly place that CustomerID in Dimension table , so we can reduce one layer inbetween Dimendion table and Master data table.Is it correct or not?
Any one can clarify my doubt.
Regards,
Arun.M.D

SID means 'surrogate ID'. That is an system created id as you know. Main purpose is fastening the search.
Mostly, there exists a rule for Customer or Material ID's.
Like it should be CHAR 10 or CHAR 16.
This kind of alpha-numeric fields are harder to search when compared to integers. Moreover, your customer id can be 10 digits but, this does not mean you will have 1000000000 customers. This is the main reason that, an internal ID is produced. If you have 10000 customers, your SID will be at most 10000.
However, if your customer ID's are starting from 1 and growing up like integers, then your argument would be true. ( but still no way to skip SID creation and direct usage of characteristic ID in fact table)
Also, as mentioned by other friends, there exist the Line Item dimension property if you have only one characteristic in one dimension. That simply does skip the DIM ID creation step, and puts your SID into the Fact table. ( Since you have only one char in the dimension, no combination is possible)
Hope this helps.
Derya

What happens when i remove Dimension table in extended star schema

*how to integrate the flex builder web dynpro and xcelsius?
i found some scenarios like when the content of the table change the chart will changes for the changed data in the table using flash islands and web dynpro.
my scenario is like this.
when i changed the chart with sliders automatically the content in the table will update to the chart level ? but both table and chart will be in the same dashboard. how can i work out this scenario using flash islands, flex and web dynpro>
thanks in Advance*

Hi Sateesh,
Please go through this URL you will get overall Idea about Extended Star schema with DIM ID's,SID's and Data flow.
http://help.sap.com/saphelp_nw70/helpdata/EN/8d/2b4e3cb7f4d83ee10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/EN/8d/2b4e3cb7f4d83ee10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/EN/8d/2b4e3cb7f4d83ee10000000a114084/frameset.htm
I hope it will help you.
Regards
Suresh B.G.

Wat is the use of sid in extended star schema rather than linking masterdat

hi bw gurus,
wat is the use of sid in extended star schema rather than linking masterdata with dimention tables?
thanx in advace,
i will assign points,
srinivas

hi,
the sid are used instead of the data in order to avoid the redunduncy of data.
and reduce the datastorage size.
the data will be present in the sid table and the data is linked used the corerponding sid in the dimension.
regards

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.

Relation between different tables in extended star schema

Hi Experts,
I searched all many threads to understand the how Attribute change run is used for
But a small question is going still.
Is attribute change run used for getting consistent data from aggregates or from infocubes.
Attribute change run is used to update the master data .Then what is the use of "activate master data "
in context menu of the master data infoobject.
Somewhere I have read that Attribute change run is used for updating Aggregates but it has got nothing to
do with Infocubes,Is it right ?
Please clarify me
Thanks in advance
Sundar

Hi Sundar,
Is attribute change run used for getting consistent data from aggregates or from infocubes.
The purpose of ACR is to update the changes happened in master data to aggregates not for aggregates.
Attribute change run is used to update the master data .Then what is the use of "activate master data "
in context menu of the master data infoobject.
when you click on activate master data, the data in P or Q or X or Y tables will get activated(if any records with version M will turned to version A)
ACR is used to update the same changes to aggregates
Somewhere I have read that Attribute change run is used for updating Aggregates but it has got nothing to
do with Infocubes,Is it right ?
Yes you are wright.here we have small logic when ACR is running if you start any rollup step it will get fail.
While ACR is running aggregates will get locked
Regards,
Venkatesh

Extended star schema implementation in rpd

joins of the tables in physical model is as follows
dim a->fact b
dim c->dim a
joins in logical table
i have created a logical table with dim a & dim c as sources ... and connected this to logical fact with fact b as one of the sources
now i want to create a measure in the fact table in which i have to use the column from dim c..
plz suggest me an approach to achieve this ...
thnks in advance

regarding aggregation rule,
it depends on your code.. that you want to write.. because...
let's go with an example...
i want to calculate A + B, where A & B are logical columns with aggregation rule sum...
Now, if you go with logical mapping (A+B), as A & B are already having Aggregation rule this will be carried to the new derived column also... this can be checked by looking at your column image(has aggregation - Sigma symbol)
better provide your code want to put in..
And, if it's sum or difference, there is no much difference if you are using logical mapping or physical mapping...
Edited by: Kishore Guggilla on Sep 20, 2010 1:01 PM

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

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

Extended Star Scheema

hai,
plz give me complete information on extended star scheeme detail explanation am expecting

Raghavendra,
Schema represents data model.
In a star-schema model, the fact table is usually very large; it can consist of millions to billions of rows. On the other hand, dimension tables are relatively small, ranging from a few thousand to a few million rows. In a typical industry standard, the dimension table contains master data. These dimension tables are specific to a fact table. This means that dimensions are not shared across other fact tables (and cubes). When another fact table, needs the same dimension data, another dimension table that is specific to a new fact table is needed. This situation creates data management problems because the very same information is duplicated in several dimension tables instead of sharing data from one single master table.
Extended star schema is an extension of a star schema. Under the extended star-schema model, the dimension tables do not contain master data. The characteristics in a dimension table point to the relevant master data by use of a SID table. The SID table points to characteristic attributes, text, and hierarchies. This multi-step navigational task adds extra overhead when executing a query. However, the benefit of this model is that all fact tables (InfoCubes) share common master data tables. Moreover, the SID table concept allows users to implement multi-language and multi-hierarchy OLAP environments. Another benefit of this model is that it also solves data analysis problems associated with the dimensions that change with time, called slowly changing dimensions.
The 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 connecte to the fact tables via the DIMID 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.
BW uses extended star schema. It means that the Fact Table will consist of some key figures and DIM ID's(Dimension ID's). These DIM ID's will reference the dimensions that are involved with a particular Fact Table. The dimensions in turn will have SID's(Surrogat ID'S) which in turn will reference the master data.
So in short the scenario is FT->DIM->Master data. The first advantage of it is Master data can reside out side of the infocube because of which the infocube size does not depend on master data(which may be huge depending on your implementation scope). The second is since the master data is outside of infocubes it is common to all infocubes that means you do not have to load master data for each infocube.
check this link
http://help.sap.com/bp_biv235/bi_en/documentation/Multi-dimensional_modeling_EN.doc
Star Schema
http://help.sap.com/saphelp_nw04/helpdata/en/e0/52029f961aa84d869b9b20fa7f7646/frameset.htm
https://websmp103.sap-ag.de/~sapdownload/011000358700007863572002E/BW_FID_35_EN.pdf
Hope this helps.
****Assign Points If Helpful****
Regards,
Gattu

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

Converting 3 tables to a star schema ??

Hi i was trying to prepare a very small demo for an OLAP system. Anyways I have a simple transaction database for a supposed Book Store anyways the database has the following 3 tables :
Table No:1
Table Name:Main Table
This Table contains the following columns:
Customer Name (PK) | Book Purchase ID (PK) | PRICE
Table No:2
Table Name:Customer Table
This Table contains the following columns:
Customer Name | CELL | ADDRESS
Table No:3
Table Name:BOOKS Table
This Table contains the following columns:
BOOK Name | Book Purchase ID | GENRE
so the above is my transactional database.. LEt me know if i am missing any other detail. Anyways now i want to convert the above to start schema ?? How would i acccomplish that .. I tried to read a couple of tutorials but i was a bit confused... so if you guys could assist me on this i would be really thnakfull.

David_Aldridge wrote:
thinking in general about this, it sounds like what you need is a set of four tables:
Dim_Cust -- stores customer details as a dimension
Dim_Book -- stores book details as a dimension
Dim_Date -- stores dates for transactions
Fct_Book_Sales -- stores the transactions themselves as the purchase of a book for a certain price by a customer on a date.
Use synthetic keys for all but the Dim_Date.Okay i kind of got lost on the way here is wht i know so far regarding the star schema
"A star schema consists of fact tables and dimension tables. Fact tables contain the quantitative or factual data about a business--the information being queried. This information is often numerical, additive measurements and can consist of many columns and millions or billions of rows. Dimension tables are usually smaller and hold descriptive data that reflects the dimensions, or attributes, of a business. SQL queries then use joins between fact and dimension tables and constraints on the data to return selected information."
so from your explaination there are going to be 3 dimension tables
Dim_Cust (Details about the customers) (Customer_ID,Cell No,Address)
Dim_Book(Details about the Books) (Book Name ,ID,Genre)
Dates (I am confused about the dates part)
Fct_Book_Sales (Confused about this part also)
and one last thing What would the fact table look like ??

BW Star Scheme & Multi dimensional Data Modelling

Hi BW Experts,
Can any one please let me know when i have to check in help.sap or serivices.sap
for detailed info on BW Star Scheema and Multi dimensional Data Modelling and how it is used in BW.
Please update me where i have to check for this info
Thanks

hi...
star schema..
Please check the threads below..
Differences between Star Schema and extended Star Schem
What is the difference between Fact tables F & E?
Invalid characters erros
mdm..
http://help.sap.com/bp_biv133/documentation/Multi-dimensional_modeling_EN.doc
hope this helps,...

Regarding Extended star schema

Similar Messages

Maybe you are looking for