Star Schema doubts?

Exepert's,
I have cube ZSAL_ANA .I am having Two dimensions 1.Sales and 2.Customer.
Sales Region contains Sales Region and Sales Location.Customer Dimension contains Customer Type and Customer location.Ok
Now Correct me if I am wrong?
In Fact table ie BIC/FZSAL_ANA we will be having keyfigures and Dimension IDs ie for Sales and Customer.
Ok ,Now The Dimension Sales (BIC/DFZSAL_ANA51) Contains only Dim Ids and
also Sids ok./BIC/SZSAL_RGN is a SID for Sales Region and it contains SID and also Sales regions. ./BIC/SZSAL_LOC is a SID for Sales Location and it contains SID and Sales Locations.
similarly for Customer Dimension (BIC/DFZSAL_ANA52).
Now /BI0/SZCUST_TPE is a SID table for Customer type.
Similarly /BI0/SZCUST_LOC is a SID table for Customer Location.
Please correct me if I am wrong?

Hi Vasu,
The 'actual' char values are stored in the S table, like SE16> /BI0/SMATERIAL. The value is not stored in the SID, but in the S table you can see each char value and the corresponding SID, like:
Material               SID
0200000000           4
0200000001           5
0200000010           6
0200000011           7
0200000020           8
0200000030           9
0200000031          10
0200000032          11
0200000033          12
Hope this helps...

Similar Messages

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

Doubt on star schema..

Hi all ,
I have a smaal doubt on Extended star schema . Like Dimension table stores only the Dim ids and corresponding SIDs and through this SID values these are linked to SID table which contains the SID for a master data . My doubt is where is our characteristics value for dimension tables . Like if one doimension if we have Employee name , college are the dimension and its master data let us assume is Employee code. CAn somebody explain me the scenario..
Thanks in advance..

Niyati,
To find the employee name, check the sid value, i.e :-
/BI0/SEMPLOYEE
Which will give you the employee number
Put this in :-
/BI0/TEMPLOYEE
and you will succeed.
Cheers,
Pom

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.

Classic Star Schema

Hi Gurus,
I have a couple of doubts related to Classic Star Schema
When SAP BW Star Schema has so many advantages as compared to Classic Star Schema, is the Classic Star Schema being used in any of the products?
If the answer is NO what are they using?
Thanks in advance.
Regards,
Neo.

Hi Neo,
Now Classic Star Schema is not used.
In a Star schema, one dimension represents one table. These dimension tables surround the fact table,which contains the facts (key figures), and are linked to that fact table via unique keys, one per dimension table. Each dimension key uniquely identifies a row in the associated dimension table. Together these
dimension keys uniquely identify a specific row in the fact table.
check this link from help.sap.
http://help.sap.com/saphelp_nw04/helpdata/en/4c/89dc37c7f2d67ae10000009b38f889/frameset.htm
The key elements of a Star schema are:<b>advantages as compared to Classic Star Schema</b>
Central fact table with dimension tables shooting off from it
Fact tables typically store atomic and aggregate transaction information, such as quantitative
amounts of goods sold. They are called facts.
Facts are numeric values of a normally additive nature.
Fact tables contain foreign keys to the most atomic dimension attribute of each dimension table.
Foreign keys tie the fact table rows to specific rows in each of the associated dimension tables.
The points of the star are dimension tables.
Dimension tables store both attributes about the data stored in the fact table and textual data.
Dimension tables are de-normalized.
The most atomic dimension attributes in the dimensions define the granularity of the information,
i.e. the number of records in the fact table.
cheers
Sunil

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 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]

Using two facts of two different star schemas and conformed dimensions

Hi,
I've been working as developer and database designer for years and I'm new to Business Objects. Some people says you can not use two facts of two different star schemas in the same query because of conformed dimensions and loop problems in BO.
For example I have a CUSTOMER_SALE_fACT table containing customer_id and date_id as FK, and some other business metrics about sales. And there is another fact table CUSTOMER_CAMPAIGN_FACT which also contains customer_id and date_id as FK, and some other business metrics about customer campaigns. SO I have two stars like below:
DIM_TIME -- SALE_FACT -- DIM_CUSTOMER
DIM_TIME -- CAMPAIGN_FACT -- DIM_CUSTOMER
Business metrics are loaded into fact tables and facts can be used together along conformed dimensions . This is one of the fundamentals of the dimensional modeling. Is it really impossible to use SALE_FACT and CAMPAIGN_FACT together? If the answer is No, what is the solution?
Saying "you cannot do that because of loops" is very interesting.
Thank you..

When you join two facts together with a common dimension you have created what is called a "chasm trap" which leads to invalid results because of the way SQL is processed. The query rows are first retrieved and then aggregated. Since sales fact and campaign fact have no direct relationship, the rows coming from either side can end up as a product join.
Suppose a customer has 3 sales fact rows and 2 campaign fact rows. The result set will have six rows before any aggregation is performed. That would mean that sales measures are doubled and campaign measures are tripled.
You can report on them together, using multiple SQL passes, but you can't query them together. Does that distinction make sense?

Injecting data into a star schema from a flat staging table

I'm trying to work out a best approach for getting data from a very flat staging table and then loading it into a star schema - I take a row from a table with for example 50 different attributes about a person and then load these into a host of different tables, including linking tables.
One of the attibutes in the staging table will be an instruction to either insert the person and their new data, or update a person and some component of their data or maybe even to terminate a persons records.
I plan to use PL/SQL but I'm not sure on the best approach.
The staging table data will be loaded every 10 minutes and will contain about 300 updates.
I'm not sure if I should just select the staging records into a cursor then insert into the various tables?
Has anyone got any working examples based on a similar experience?
I can provide a working example if required.

The database has some elements that make SQL a tad harder to use?
For example:
CREATE TABLE staging
(person_id NUMBER(10) NOT NULL ,
title VARCHAR2(15) NULL ,
initials VARCHAR2(5) NULL ,
forename VARCHAR2(30) NULL ,
middle_name VARCHAR2(30) NULL ,
surname VARCHAR2(50) NULL,
dial_number VARCHAR2(30) NULL,
Is_Contactable CHAR(1) NULL);
INSERT INTO staging
(person_id, title, initials, forename, middle_name, surname, dial_number)
VALUES ('12345', 'Mr', 'NULL', 'Joe', NULL, 'Bloggs', '0117512345','Y')
CREATE TABLE person
(person_id NUMBER(10) NOT NULL ,
title VARCHAR2(15) NULL ,
initials VARCHAR2(5) NULL ,
forename VARCHAR2(30) NULL ,
middle_name VARCHAR2(30) NULL ,
surname VARCHAR2(50) NULL);
CREATE UNIQUE INDEX XPKPerson ON Person
(Person_ID ASC);
ALTER TABLE Person
ADD CONSTRAINT XPKPerson PRIMARY KEY (Person_ID);
CREATE TABLE person_comm
(person_id NUMBER(10) NOT NULL ,
comm_type_id NUMBER(10) NOT NULL ,
comm_id NUMBER(10) NOT NULL );
CREATE UNIQUE INDEX XPKPerson_Comm ON Person_Comm
(Person_ID ASC,Comm_Type_ID ASC,Comm_ID ASC);
ALTER TABLE Person_Comm
ADD CONSTRAINT XPKPerson_Comm PRIMARY KEY (Person_ID,Comm_Type_ID,Comm_ID);
CREATE TABLE person_comm_preference
(person_id NUMBER(10) NOT NULL ,
comm_type_id NUMBER(10) NOT NULL
Is_Contactable CHAR(1) NULL);
CREATE UNIQUE INDEX XPKPerson_Comm_Preference ON Person_Comm_Preference
(Person_ID ASC,Comm_Type_ID ASC);
ALTER TABLE Person_Comm_Preference
ADD CONSTRAINT XPKPerson_Comm_Preference PRIMARY KEY (Person_ID,Comm_Type_ID);
CREATE TABLE comm_type
comm_type_id NUMBER(10) NOT NULL ,
NAME VARCHAR2(25) NULL ,
description VARCHAR2(100) NULL ,
comm_table_name VARCHAR2(50) NULL);
CREATE UNIQUE INDEX XPKComm_Type ON Comm_Type
(Comm_Type_ID ASC);
ALTER TABLE Comm_Type
ADD CONSTRAINT XPKComm_Type PRIMARY KEY (Comm_Type_ID);
insert into comm_type (comm_type_id, NAME, description, comm_table_name) values ('23456','HOME PHONE','Home Phone Number','PHONE');
CREATE TABLE phone
(phone_id NUMBER(10) NOT NULL ,
dial_number VARCHAR2(30) NULL);
Take the record from Staging then update:
'person'
'Person_Comm_Preference' Based on a comm_type of 'HOME_PHONE'
'person_comm' Derived from 'Person' and 'Person_Comm_Preference'
Then update 'Phone' with the number based on a link derived from 'Phone' which is made up of Person_Comm Primary_Key where 'Comm_ID' (part of that composite key)
relates to the Phone table Primary_Key which is Phone_ID.
Does you head hurt as much as mine?

Star schema in OBIEE 11G

Hi Experts,
Please tell me the places in OBIEE 11G where i can design the start schema.is it only in Physical Layer or In BBM too?
Thanks-Bhaskar

Final point, for performance reasons you should also try to model data into star schema in the physical layer.
If the data is modelled as a true star then there are database features which optimise query performance. These features are set by a DBA when the Warehouse is configured (e.g. enable_star_transformations). The results with this parameter on/off can be staggering (query time reduced from minutes to seconds), showing the power of star schema.
When snowflakes occur, these performance features will not work as designed, and performance will be degraded. There are certain criteria that have to be met by the data e.g. bitmap indices on all of the foreign key columns in the fact.
Please mark if helpful / correct,
Andy
www.project.eu.com

Error with creating star schema using HsvStarSchemaACM

Hi,
I am trying to create a star schema using the API HsvStarSchemaACM. But when calling the create function of API, i get the below exception. Exception from HRESULT: 0x80040251 (A general error occurred while trying to obtain a database Reader/Writer lock). Is this something to do with the parameters passed and its connections(connection works fine and createstarschema is running thru workspace).
Any solutions to this is more welcome.
Thanks,
Logu

Can you provide details on HsvStarSchemaACM API? How is it related to ODI?

Resolving loops in a star schema with 5 fact tables and 6 dimension tables

Hello
I have a star schema, ie 5 FACT tables and 7 dimension tables, All fact tables share the same dimension tables, some FACT tables share 3 dimesnsions, while other share 5 dimensions.
I did adopt the best practices, and as recommended in the book, I tried to resolve them using Context, as it is the recommended option to Alias in a star schema setting. The contexts are resolved, but I still have loops. I also cleared the Multiple SQL Statement for each context option, but no luck. I need to get this resoved ASAP

Hi Patil,
It is not clear what exactly is the problem. As a starting point you could set the context up so that it only covers the joins from fact to dimension.
Fact A, joins Dim 1, Dim 2, Dim 3, and Dim 4
Fact B, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 5
Fact C, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 6
Fact D, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 7
Fact E, joins Dim 1, Dim 2, Dim 4 and Dim 6
If each of these are contexts are done and just cover the joins from fact to dim then you should be not get loops.
If you could lay out your joins like above then it may be possible to specify the contexts/aliases that should work.
Regards
Alan

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 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 doubts?

Similar Messages

Maybe you are looking for