Download IBM Book on Star Schema Design (Dimensional Modeling)

Hello Friends,
You can download an IBM Book on Dimensional Modeling from the following link:
http://www.redbooks.ibm.com/redbooks.nsf/e9abd4a2a3406a7f852569de005c909f/e235dc46161249d38525703e00036135?OpenDocument
The Book is very well explained.

Dear Krish,
Please try this link and let me know if you can open.If not I will email you the Book:
http://www.redbooks.ibm.com/abstracts/sg247138.html?Open
My Email is [email protected]
Thanks
Dave

Similar Messages

Download Dimensional Modeling Book (Star Schema Design Book)

Hello Friends,
You can download an IBM Book on Dimensional Modeling from the following
link:
http://www.redbooks.ibm.com/abstracts/sg247138.html?Open
This is an excellent IBM Redbook on Data warehouse design and
Dimensional Modeling design.
Great to read,
Dave

Dear Krish,
Please try this link and let me know if you can open.If not I will email you the Book:
http://www.redbooks.ibm.com/abstracts/sg247138.html?Open
My Email is [email protected]
Thanks
Dave

Star schema design, metrics dimension or not.

Hello Guys,
I just heard from one of my colleagues that its wise to
have an "KPI" or "metrics" dimension in my DWH star schema (later used in OBIEE).
Now, we have quite a lot of data 100 000 rows per day (botton leve, non-aggregated, the aggregations are obviously far less then that, lets say 200 rows per day) and
we have build pre-aggregated data marts for each of the 5 very static reports (OBIEE Publisher).
The table structure is very simple
e.g.
Date,County,NumberofCars,RevenuePerCar, ExpensesPerCar, BreakEvenPerCar, CarType
One could exclude the metrics "NumberofCars","RevenuePerCar", "ExpensesPerCar", "BreakEvenPerCar"
and put them into a metrics dimension.
MetricID Metric
1 NumberofCars
2 RevenuePerCar
3 ExpensesPerCar
4 BreakEvenPerCar
and hence the fact table design would be simpler.
Date,County,MetricID,Metric, CarType
Disadvanatages: A join is required
We would have to redesign our tables
tables are not aggregated anymore for specific metric types
if we notice performance is bad, we would need to go back to the old design
Advantages : Should new metrics appear, we dont have to change the design of the tables
its probably best practice
Note: date, country and cartype are already dimensions. we are just missing one to differentiate the metrics/KPI's
So I struggle a bit, what should I do? Redesign, or stick to the way I have done it, having
performance optimization in mind.
Thanks

"Usually the date is stored in sales table or product table.
ut here why they created separate Dimension table for date(Dim_date)? "
You should provide the link.
A good place to start with the basic concepts is :
http://www.ralphkimball.com/
Pick up some of his books and start going through them.
My recommendation would be
The Data Warehouse Toolkit, 2nd Edition: The Complete Guide to Dimensional Modeling
John Wiley & Sons, 2002 (436 pages
Good Luck.,

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

STAR schema designing

Hi,
What are the factors or the things that we should consider while designing star schema ?
Thanks
Vaishali

Vaishali,
The major things to be considered while designing start could be ..
1. Proper maintenance of Master data which will be shared across all the infocubes.
2. Deciding upon dimensions. Which characteristics should be assigned to which dimension? Try to reduce the number of dimensions.
3. Design deimensions based upon the characteristic relation 1:M...
4. If the char has more no of values for eg, document number which come in huge volumes to BW that can be designed as Line item dimension instead of assigning it to a dimension.....
Hope this helps you.....

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

Designer - Dimensional modeling

Can Designer do Dimensional modeling ???
Welcome replies directly to my personal email.
Thanks!

Hi Rajiv,
I'm no expert either and am just beginning to learn HANA, but here are my thoughts (community, please correct me if I am mistaken.):
1. HANA leverages existing data modeling theories, such as the entity relationship model. This model is simply a way of organizing tables in a way that makes sense for reporting. For example, the star schema, optimized for analytical reporting. The HANA view is similar to a universe, it allows the end user to connect to it from their BI tool. In the background, the modeler still needs to pull in tables, create joins, leverage primary and foreign keys, etc. So in short, traditional modeling practices and theories still come into play.
2. If extracting and transforming data using SAP's Data Services, the transformation of data will happen in HANA, using the Data Quality Management GUI.
Just as a side note, HANA has 3 methods of extracting
data:
Data Services
SAP Replication
Server
SAP Landscape
Transformation
3. Yes, dimensional modeling is still required. At the end of the day, HANA is still a database. We
haven’t changed the theory of data modeling, it still needs to happen, our approach is just different.
Hope that helps.
Kyle

Designing Dimensional Model from Reports

I'm currently desiging a data warehouse for our project. My problem is that we do not have access to the source system. The only thing we are provided with is the data feeds that are generated by the current reporting system. This is causing me a great deal of headach b/c reports do not give you an entire picture of what the source system. Since reports only display data based on how it is developed, it is difficult to come up with an efficient design. My question is has anyone designed a dimensional model using only Reports as the source?

Hi there,
The short answer to your question is 'no'
A longer answer is 'Surely it is possible to get a copy of the source schema definition even if it is not possible to get access to the source system?'
Stuart

Star schema design question

Hi!
I`m trying to build a dw with patient data. I`m mostly interested in the patients` visits table, which will be used for a facts table and the patient table.
The patient table contains among others the following data:
patient (id, sex, marital_status, nationality, profession, zip).
My question is what should I do with the "patient" table. There seem to be three options:
1. Use it to build a one level dimension and just use the above fields as simple dimension attributes.
2. Create separate hierarchies for each attribute in the patient dimension
(e.g. patient -> sex, patient -> nationality, patient -> zip -> city e.t.c.)
3. Create separate dimensions for each attribute (e.g. a professions dimensions which will be joined with the patient visits facts table) and no patient dimension.
What would you do?
Thank you...

I guess my answer would be based on how you intend to physically implement. If you are deploying this relationally, then I would definitely have a single patient dimension table. Perhaps build a hierarchy for patient -> zip -> city, but I'd keep gender and nationality as simple "attributes" of the dimension.
If you're going to deploy this through an OLAP cube, its a bit more complex, because the standard Oracle OLAP functionality makes it impossible to do sums over attributes unless they are part of the hierarchy. In that case, I guess I'd deploy multiple dimensions (geneder, nationality, one a generic patient one that includes the hierarchy patient -> zip -> city).
If you attempt to do your option #2, you'll be in trouble if you need to show queries that cross the hierarchies, i.e. "Male American patients who live in zip code 12345".
Hope this helps,
Scott
p.s. you could also deploy this relationally, and then put an AW on top of the relational model.

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?

How you we design and create a star schema in Oracle BI?

We can use Informatica to generate ETL. But how do we design the star-schema?? Is there a design tool like Oracle Designer??
What is the purpose of the DAC??

Hi,
You can handle the star schema design in the BMM layer. No separate tool for that.
Refer-
http://gerardnico.com/wiki/data_modeling/star_schema
DAC-
Data Warehouse Application Console (DAC) works together with Informatica to acomplish the ETL for pre-packaged BI application.
- DAC publish the changes from OLTP
- Informatica extracts the changes from the change log published by DAC as well as from the base table
- Informatica load the data to the stage tables and the target tables in the data warehouse
- DAC manage the performance by dropping indexes, truncating stage tables, rebuilding the indexes, and analyzing the tables during the process
If you do not use DAC, you have to write your own custom change capture process and need to redesign from scratch an ETL method that allow the restart of the ETL process from point of failure at record level. The biggest saving is that DAC can survive during the upgrade , while your custom processes cannot.
Refer-
http://obieetraining11.blogspot.in/2012/06/how-to-use-dac-source-system-parameter.html
Hope this helped/ answered.
Regards
MuRam
Edited by: MuRam on Jun 25, 2012 2:37 AM

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

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.

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.

Excellent Dimensional Modeling /star Schema Book by IBM for free downlaod

Hello Friends,
You can download an IBM Book on Dimensional Modeling from the following link:
http://www.redbooks.ibm.com/abstracts/sg247138.html?Open
This is an excellent IBM Redbook on Data warehouse design and Dimensional Modeling design.
Great to read,
Dave

Dear Krish,
Please try this link and let me know if you can open.If not I will email you the Book:
http://www.redbooks.ibm.com/abstracts/sg247138.html?Open
My Email is [email protected]
Thanks
Dave

Download IBM Book on Star Schema Design (Dimensional Modeling)

Similar Messages

Maybe you are looking for