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

Similar Messages

  • Modeling Star Schema From Transactional Schema

    My requirement is to model the BMM from a Transactional Schema. When creating the joins in the physical layer for example between the Customer and Orders table would I join the 2 tables on Customer ID and pay attention to the one to many relationship between a customer and orders or would I need to defined which table is the fact table and which table is the dimesion table before creating the joins in the physical layer.

    I would suggest to write a physical query to generate report like year, customer,product wise #of order and order items. Based on that try to creat joins and the bmm schema. I would say this the best approach.
    Or else look for the table which having more foreign keys to other tables that would be the center located table.
    Pla mark if helps.

  • Booking Customs Duty for Free Import Material

    A standard import procurement cycle is as follows.
    Customs duties are applied as planned delivery costs in the pricing procedure in PO. The vendor for the customs conditions is changed to 'customs vendor'
    1. MIRO is done against PO to pay the duties to customs (planned del costs)
    2. GR done against PO (referencing customs MIRO)
    3. Finally, MIRO to pay the vendor.
    Scenario:
    Now I have a PO for a free of cost material but the entire duty has been paid to the custom vendor.
    I created a PO with the custom conditions but when I tick the 'Free item' indicator
    the price as well as the condition tab disappear.
    How do I go about booking the MIRO to pay the custom duties?
    Regards
    S Datar.

    Hi Satyajit
    1) Maintain normal PO including net value and othe duty conditions
    2) Process MIRO for goods and delivery costs simultaneously.
    3) Maintain zero amount for goods item and actual values for the duties (Ensure selection of goods item including delivery cost items)
    4) Save the IV document
    5) Observe PO item history got updated with IR-L and DCIn. (IR-L will updated with zero amount)
    6) Then go ahead with MIGO w.r.t. IR document
    7) GR FI document will get updated with the non-set off duty values only.
    warm regards
    sairam akundi

  • I put my ipad into dfu mode, by mistake, and now have to restore it. Can I redownload all the paid apps (And Books) on it for free?

    This was a TOTAL mistake. I had no idea what I was doing. I put my iPad into DFU mode, and now have to restore it. (That didnt end well, knowing I had just bought a bunch of books and apps) I want to know, after I restore my iPad can I go into the app store or iBooks and redownload the books and apps I had originaly payed for? Thanks for the help

    Yes, App Store and iBooks have a "Purchased" tab, allowing you to re-download at no additional charge.
    But that may not be necessary if you restore from a backup. You might be able to get all of your content back from the restore.

  • Normalized (3NF) VS Denormalized(Star Schema) Data warehouse :

    what are the benefits of normalized data warehouse (3NF) over the denormalized (Star schema)?
    if DW is in the 3NF then is need to create the seprate physical database which contains several data marts( star schema)with physical tables, which feeds to cube or create the views(SSAS data source view) on top of 3NF warehouse of star schema which feeds to
    cube?
    please explin the pros and cons of 3NF and denormalized DW.
    thanks in advance.
    Zaim Raza.

    Hi Zaim,
    Take a look to this diagram:
    1) Normally, 3NF schema is typical for ODS layer, which is simply used to fetch data from sources, generalize, prepare, cleanse data for upcoming load to data warehouse.
    2) When it comes to DW layer (Data Warehouse), data modelers general challenge is to build historical data silo.
    Star schema with slow changing facts and  slow changing dimensions are partially suitable.
    The DataVault and other similar specialized methods provides, in my opinion, wider possibility and flexibility.
    3) Star schema is perfectly suitable for datamarts. SQL Server 2008 and higher contains numerous query analyzer improvements to handle such workload efficiently. SQL Server 2012 introduced column stored indexes, that makes possibility to
    create robust star model datamarts with SQL Query performance comparable to MS OLAP. 
    So, your choice is:
    1) Create solid, consistent DW solution
    2) Create separate datamarts on top of DW for specific business needs. 
    3) Create necessary indexes, PK, FK key and statistics (of FK in fact tables) to help sql optimizer as much as possible.
    4) Forget about approach of defining SSAS datasource view on top of 3NF (or any other DWH modeling method), since this is the way to performance and maintenance issues in the future.

  • Metadata Repository : star schema

    hi,
    *how do you export star schema to excel?*

    Hello,
    Star schema is a Concept on which BW is based. If you want to transport Star Schema to Excel, you should instead look at all the Dimension tables, associated Fact tables, master data tables, SID tables for it to make sense.
    Hope this helps.
    Regards

  • Newbie question : why is star schema fast and efficient?

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

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

  • 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

  • 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

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

  • How to join  2 star schemas  using a Dimensional table( like Bridge Table)

    How to join 2 star schemas using a Dimensional table( like Bridge Table) in OBIEE?

    Complex joins and Content levels is all you need, have you tried the forum search?

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

  • 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

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

  • Are there any (dis)advantages in building a universe on fully normalized tables instead of building dimensional model/tables and then universe on top of them?

    Hello,
    I’m hoping someone can help me with understanding advantages and disadvantages if we want to build a universe on top of a fully normalized tables, compared to using a dimensional model with star schemas.
    I’ve read some discussions here that say that it is possible to create a universe on top of normalized tables. Then, can we avoid building of dimensional tables (a data mart), and just use normalized tables? I would say that it is easier to use star schema dimensions and facts tables to build a universe, but our end users might ask “why do we have to go through building a dimensional data mart, if we can have same reports with hierarchies and drill-down functionality based on a universe built on top of our already existing normalized tables?”
    Can you point me to some established best practices regarding using normalized tables to build a universe? Any documents with some examples for this?
    Any expected difficulties during design/development phase of our universe, related to using normalized tables?
    Any expected performance degradation if we use normalized tables compared to using dimensional tables?
    Can I build universe more easily if I transform (modify) our normalized model (by using alias tables and views) to look like snowflake model?
    I’m using BOE XI 3.1, tables are in Oracle 11.2.
    Thank you

    Few Disadvantages that I usually face when building universe on Normalized tables,
    1. Performance - Read operations have to suffer because indexing strategies do not go well with table joins
    2. Derived Tables - Due to complex Queries/ Logic, most of the time, end-up creating derived tables, which doesn't use back-end table indexes and slows down the report runtime.
    3. Normalized table/ Transaction tables may not always have proper cardinality and often results in Cartesian products
    4. Normalized tables may not have tight referential integrity and may have to join more than one column and join on varchar, etc whereas, good Dimensional model datawarehouse will have proper keys/ integer joins and not always necessary to join on multiple fields
    5. Often deal with Fan and Chasm Traps
    6. Dealing with Database fields with nulls, blanks, date in numeric format, etc.,
    7. No Facts, Dimensions separated and most of the time they are in same table
    and More...
    If performance is not a matter and building Datawarehouse is a big deal, then I will start building Universe on normalized tables by having the database diagram as reference for Joins, contexts, etc
    Note: After dealing with universes based on normalized tables for few years (by creating views, complex sql queries data loading to tables and unv on these tables, derived tables), I ended up creating star-schema dimensional model (couple of months extra ETL work), users/ developers felt lot better when they have to create standard/ ad-hoc reports and they are super fast compared to previous universes.

Maybe you are looking for