Factless fact tables????

Hi gurus,
Anybody please tell me about factless fact tables? in what are all the scenarios we can use it? Can we create Infocube without key figures?
Thanks,
Karthik T

Hi Karthik,
Please go through this....
A "factless" fact table is generally one which records instances of
time-bound relationships, rather than capturing transaction amounts. The
example usually given by Kimball is a fact table which records the
instances of students, professors, and classrooms reserved for specific
classes at a college. In this case, the "key figure" is simply a binary
switch indicating the truth of a relationship expressed by the
characteristics in the dimension tables (the "zero", or false, instances
are not stored.)
Look at the delivered BW Headcount / Employee Action cube, 0PA_C01, for a
rough facsimile of the "factless fact table." To implement such a thing in
BW, you still need a key figure -- usually an integer (quantity) holding
the value 1 (at the most granular level of detail,) indicating that a
relationship expressed in the dimension characteristics is true. You can
populate a cube like this by reading information from master data tables in
your update rules, with your datasource driving off your most granular
master data table. Again, see the delivered datasources and update rules
for the 0PA_C01 cube to see how SAP does it.
Assign pts if helpfull
Thanks,
Sujeet

Similar Messages

  • Deploying Factless Fact Tables in 10G

    Hello - We are trying to deploy the same factless fact tables we used for OWB 9i to 10G and we are receiving validation errors saying that every cube must have a measure. We do not want to create a null column just to get around something that worked fine in a previous version of the tool, and we have quite a few factless fact tables in our model.
    Are there any thoughts on this?
    Thanks,
    Kristi

    Hi,
    I already face that kind of fact table, but in the same time, i needed to count the number of intersection between dimensions or sum, so i used a one measure, that always takes 1 as value, that did the trick.
    Regards

  • Bridge table or factless fact table?

    Hello,
    I have a model a bit different that I've worked with in OBIEE (10), and I can't make it work. I have 1 fact table and two dimensions, joined this way in the physical layer:
    Fact Table >- Dim Person -< Dim Address
    The join between Fact Table and Dim Person is 1:N and the join between Person and Address is also 1:N, for example one person can have many addresses.
    I have searched in forum, internet, etc. how to model this in the BMM, but I can't find the same model as an example. I have found similar models solved with a bridge table, but the model is a bit different (Fact Table -< Dim Person >- Dim Address), so it won't help.
    I have tried many things, but the option that I thought it's more logic, is treating Dim Address as a factless fact table. However, when I choose in a report a fact from the real Fact Table, the person ID and the address, the fact was treated as null. What I expect is that the fact table should be repeated for every address that the person has. So, if the fact is 3 for one person, and the person has 4 addresses, the result should be 4 lines with the value 3 in each of them.
    Can I make Dim Address be a factless fact table in the BMM? Should I include the Dim Address in the LTS of a single logical table? Is Dim Person a bridge table??
    I hope you can help me with this one, thanks!

    I'm not sure how much info you need to show on the reports, but you can try creating 2 separate logic schemas with alias tables.
    1) Create alias table for fact and Dim Person and join them
    2) Create another alias for fact (Fact1) and Address (always thinking that the perdon ID is also in the Address table) and join them.
    Try to make your report between fact1 and address (in this case you can't put detail of the person,but you can make another report showing the persona information using the first schema.
    J.

  • "Factless" fact table join warning

    We have a physical fact table that only contains keys for a given day in order to track changes to Employment history over time. The compensation "facts" are contained in a dimension that is joined to the factless physical table in the logical layer. I use the factless fact as the table source and inner join it to the dimension to create the logical fact source. This seems to be working fine, but is creating a warning when I check consistency: "There are physical table sources mapped in Logical Table Source [...] that are not used in any column mappings or expressions." Is there a better way to model this in the logical layer that this warning is trying to alert me to?
    Thanks!

    Thank you,
    The error does go away when I insert into the logical fact table the key from the factless physical table. The error is gone whether or not I define the physical column as the Logical fact table key. Will defining it as a logical key change anything?
    I am curious as to why it would want me to include a field in the fact table that will never be used in the presentation layer. Is the warning mainly for accidental inclusion of physical tables that aren't used?
    Thank you for the response. Nice blog by the way.

  • Can date be included in the fact table as a measure?

    Dear All,
    I have to migrate a database form relational model to dimensional model. It a kind of human resource database. I don't know what MEASURES should I keep in the fact table. There are only dates, like date the employee joined the institution and the date he will leave. Most of the other fields are non-numeric. well date is also non-numeric but we can calculate the duration the employee worked from these dates.
    What do you suggest?

    I'd be careful about adding a "measure" of duration worked (be it days, months, years - doesn't matter). Causes lots of churn. For example, if you choose a measure of "duration_worked_in_days" - every single row in the fact table would be obsoleted every single day....
    What types of questions do you expect the fact table to answer?
    I'm working on a HR mart right now, and my fact data is around pay rates (not actual pay), i.e. annual salary, hourly salary, etc. My records also have two "date" dims - effective start date and effective end date. Meaning if my annual salary is $50 a year between 1/1/2008 and 12/31/2008, that's what the row shows. When (or if) I get a pay raise (/cut), the "current" record gets end dated, and a new record inserted.
    When you say that a fact table "must" contain measure columns - I assume you're using the actual OWB fact / dimension objects, vs. just tables? Very common in a HR data warehouse to have a "factless" fact table.
    Hope this helps,
    Scott

  • Answers on factless facts

    Hi,
    How does OBIEE, Answers in particular, cope with factless fact tables? The related dimensions would be linked to that factless fact in the pysical and BMM tier, but the factless fact would not be shown in the subject area.
    When an user selects two or more dimensions linked through this factless fact, how would BI Server generate the query?
    Is it recommended to have a least a dummy measure in that fact?
    Thank you!

    Hy,
    I have an example here :
    http://gerardnico.com/wiki/dat/obiee/bi_server/design/obiee_densification_design_preservation_dimension
    I don't use a factless fact table but a densification process.
    The techniques used are the same as it's based on the fact vertical partitioning.
    http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/obiee_fact-based_partitioning_outer_joins
    And you can see the two queries and the full outer join issued.
    Success
    Nico
    And thanks Stijn (I didn't know the implict fact)

  • IMPLICIT FACT & FACTLESS FACT

    Hello Gurus
    Can anybody please explain what is implicit fact and for what is it used for .
    And also
    Can anybody please explain Fact Less Fact and for what it is used for .

    follow this,
    1. open administration tool
    2. go to help
    3. click on Search tab
    4. type Implicit Fact
    5. only one topic you'll findin the results.. plz read it and let me know your doubts on that..
    coming to your next question...
    Factless Factohhh, got these links after googling..
    http://www.geekinterview.com/question_details/31538
    http://dylanwan.wordpress.com/bi-and-olap-glossary/factless-fact-table/
    http://www.allinterview.com/showanswers/36017.html

  • Conformed dimensions across several fact tables

    Hi, not exactly sure how to phrase my question, so I'll just start babbling and maybe it'll come across. In our OBIEE repository (from BI applications "project analytics"), we have dimensions of CONTRACT, CONTRACT LINE, PROJECT, and TASK (CONTRACT and CONTRACT_LINE really come from a single dimension table, but are different rows and so really can be thought of as coming from two different dim tables). TASKs are really children of projects - but they were broken out into a separate dimension in the data model (no idea why....). Also, in our business, a task can be tied to one and only one contract line.
    Now here's the rub - because TASK is a separate dimension from PROJECT, there is really nothing that relates them except through a fact table. This is a real pain, as it has two limitations:
    1) If a "fact" for that combination of PROJECT / TASK hasn't happened yet, then no row in fact table = nothing that says they are related
    2) Even if you do have a fact for everything - now our query is scanning through a fact table of (in our case) 300+ million rows, just to say which task is tied to which project
    I'd like to solve this by creating a very simple "factless fact" which has columns for CONTRACT, CONTRACT LINE, PROJECT, and TASK, and simply inserts the appropriate surrogate IDs (wids) into this. Thus, instead of a 300+ million row fact table, we should be down to only 400,000 or so task / project / line / contract combos.
    Now here's my question: I have a "combined" subject area that includes a project cost, project revenue, project billing, and in theory this new fact table I'm talking about. I'd want to set the new fact table to be the "implicit" fact - so that if someone just asks a questions like "show me contract lines, and which projects and tasks are assigned to it" - it would go to the new, slim, fast fact table.
    But I'm concerned about what happens when someone then throws in a cost amount, revenue amt, etc. onto the query. I'm assuming that OBIEE will be smart enough to understand it should forget the implicit fact, and start using the "real" facts. Or maybe use all of them including the new fact.
    I'm just trying to see if I can anticipate this causing any issues.
    Thx,
    Scott

    You are correct, the implicit fact will only be used when there isn't any other fact measure defined in your query. Unfortunatelly you can only define an implicit fact per SA, we would love to be able to have more flexibility such as defining them per dimension etc. Another way to "force" OBIEE to select from an specific fact is to select a column from it in your Answers query. You don't to see this column in output so you can hide it. Of course this "hack" is not really very user friendly as it makes adhoc query building much more complex.

  • Relationship between Dimension without linking Fact table

    Hi,
    My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
    including any measures from fact table .
    Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but  not linked to each other directly  but can I get right result when I want to know what are the manufacturer for each product? or list of
    customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
    regards
    Sanjoy ghosh 

    Hi Sanjoy -
    The answer to your questions depends on your dimensional design and exactly what the fact table represents.  Fact tables naturally capture the intersection of the different dimensions.  This is true whether you physically implement a
    PK - FK relationship in the relational db.  
    In your case, since customer is involved, sounds like a sales transaction fact.  If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
    For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely.  Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
    across to product.  If you need to solve this question, you have some other options:
    - flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
    - embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
    to be flattened onto the product)
    - build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates.  This would allow you to capture rich details about each dimension separately
    and use the factless fact to record)
    Let me know if that helps.
    Brent Greenwood, MS, MCITP, CBIP
    // Please mark correct answers and helpful posts //
    http://brentgreenwood.blogspot.com

  • Logical level in Fact tables - best practice

    Hi all,
    I am currently working on a complex OBIEE project/solution where I am going straight to the production tables, so the fact (and dimension) tables are pretty complex since I am using more sources in the logical tables to increase performance. Anyway, what I am many times struggling with is the Logical Levels (in Content tab) where the level of each dimension is to be set. In a star schema (one-to-many) this is pretty straight forward and easy to set up, but when the Business Model (and physical model) gets more complex I sometimes struggle with the aggregates - to get them work/appear with different dimensions. (Using the menu "More" - "Get levels" does not allways give the best solution......far from). I have some combinations of left- and right outer join as well, making it even more complicated for the BI server.
    For instance - I have about 10-12 different dimensions - should all of them allways be connected to each fact table? Either on Detail or Total level. I can see the use of the logical levels when using aggregate fact tables (on quarter, month etc.), but is it better just to skip the logical level setup when no aggregate tables are used? Sometimes it seems like that is the easiest approach...
    Does anyone have a best practice concerning this issue? I have googled for this but I haven't found anything good yet. Any ideas/articles are highly appreciated.

    Hi User,
    For instance - I have about 10-12 different dimensions - should all of them always be connected to each fact table? Either on Detail or Total level.It not necessary to connect to all dimensions completely based on the report that you are creating ,but as a best practice we should maintain all at Detail level only,when you are mentioning any join conditions in physical layer
    for example for the sales table if u want to report at ProductDimension.ProductnameLevel then u should use detail level else total level(at Product,employee level)
    Get Levels. (Available only for fact tables) Changes aggregation content. If joins do not exist between fact table sources and dimension table sources (for example, if the same physical table is in both sources), the aggregation content determined by the administration tool will not include the aggregation content of this dimension.
    Source admin guide(get level definition)
    thanks,
    Saichand.v

  • Parent member values in Fact tables

    Hello,
    I want to understand something, as far as I know, we can only send data to base level members, right ?
    Then how come we find rows of data that have parent member values in the Fact tables ? (assuming we do not play manually with the database of course), I thought that this can be due to an import with the data manager, can this be right ?

    nilanjan chatterjee wrote:
    Hi,
    >
    > The data for the parent members should be available in the SQL tables.
    > For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
    >
    > Hope this helps.
    I guess you meant should not, right ?

  • Null key in fact tables

    Hi all,
    I have one role play dimension with some null key in fact table, I liked know if it's a good practice?
    thanks

    Depends on what you actually mean..
    When one dimension column contains NULL in your fact table, then it's normally a bad practice. Create a entry in your dimension table to represent this state.
    The problem is that NULL is a state, which means does missing or inapplicable information. This means that the row in the fact table is semantically meaningless. Cause your fact table is no longer additive over this dimension.

  • Help on  Setting logical Levels  in Fact tables and on Dimension tables

    Hi all
    Can any body provide any blogs or any king of material on what exactly is levelling .
    Like after creating the Dimensional hierarchies we need to set the logical levels for the LTS of fact tabels ri8 .So what is the difference between setting logical levels to fact tabels and also Setting levelling on Dimension tables .
    Any kind of help is appreciated
    Thanks
    Xavier.
    Edited by: Xavier on Aug 4, 2011 10:50 AM

    I have read these blogs ,but what my question is
    Setting the logical levels in LTS of Fact tables i understood .
    But we can also set the logical levels for dimensions also ri8 .I didn't understand why do we set the logical levels for dimensions .Is there any reason why we go with the levelling at dimensions
    Thanks
    Xavier
    Edited by: Xavier on Aug 4, 2011 2:03 PM
    Edited by: Xavier on Aug 4, 2011 2:32 PM

  • Logical level for logical fact table sources

    it is clear that for fact aggregates, we should use the Content tab of the Logical Table Source dialog to assign the correct logical level to each dimension.
    question is : is it mandatory to assign even for non-aggregates fact tables the logical level for each dimension (which normally should be set to the most detailed level of each dimension) ? is it any known issue if "logical levels"in content tab are not set ?
    the reason I'm asking this is a strange bug I have (I'm not going to discuss it here) and then only workaround seems to be NOT setting the logical levels (on content tab) for logical fact table sources.
    thank you !

    If levels are not set: By default levels are considered as lowest level
    It should not matter if you set or not
    Generally we set for facts explicitly when we are using Aggregate tables.
    Your current issue might be a case by case; I would suggest to check implicit fact, any table mapped to the source to force a join etc
    Mark if helps
    Let me know how it helps
    Edited by: Srini VEERAVALLI on Feb 5, 2013 8:33 AM
    Any updates on this?+_
    Edited by: Srini VEERAVALLI on Feb 14, 2013 9:09 AM

  • Best way to combine multiple fact tables in single mart

    Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
    I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
    For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
    I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
    However, I'm not quite sure how to proceed at the month level. My initial thought is:
    a) create a new LTS for the fact table at the month level
    b) in the new LTS, add the join to the time dimension
    c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
    Is this the proper way to do this?
    Thanks in advance!
    Scott

    Hi Scott,
    I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
    DAILY_FACT (
    DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
    START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
    END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
    DAILY_VALUE NUMBER); -- FACT MEASURE
    MONTHLY_FACT(
    MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
    MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
    MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
    DIM_DATE(
    DATE_KEY NUMBER,
    DATE_VALUE DATE,
    DATE_MONTH VARCHAR2(20),
    DATE_YEAR NUMBER(4));
    DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
    Step 1)
    Make the following three joins in the physical layer:
    a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
    b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
    C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
    Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
    Step 2)
    Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
    Step 3)
    Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
    Step 4)
    Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
    Step 5)
    Drag all required reporting columns to the Presentation layer.
    Step 6)
    Create your report using the two different measures from the different fact tables.
    Step 7)
    Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
    Step 8)
    You're done.
    The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
    Hope that helps!
    -Joe
    Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

Maybe you are looking for

  • Graphics/ images such as book covers do not appear on amazon website. Text appears instead of image.

    When going to the web site amazon.com the extensive graphics does not appear. Where there should be an image of a book, instead there is text. I have tried reinstalling Firefox and it does nothing. Other than this image problem Firefox works fine. Ph

  • BC4J/JSP:Foreign Keys:Read Only Renderers

    I've read and implemented all of the Renderers in the Renderer how to document. I've also read 8 pages of postings to this forum regarding renderers and LOVs. And I've read reams of BC4J class documentation. Though the EditRenderer that does a lookup

  • Changing appearance of active spreadsheet cell

    This is a question our school secretary asked of me. She has recently upgraded from an eMac to a new iMac. She works quite a bit in spreadsheets. In a spreadsheet, the active cell is outlined in light blue, which she finds hard to see, especially if

  • Clearing Customer Accounts with a credit balance

    Hello Gurus, We have a requirement to use automatic clearing to clear down customer accounts where the credits exceed the debits and leave an AB document on the customers account for the remaining credit balance. I think I should be able to acheive t

  • Does time machine backup iPhoto in an optimized way?

    Question: When TM backs up iPhoto, does it save a whole new copy of the library each time, or does it somehow sort of record the changes only? I'm concerned about filling up TM too fast with a bunch of copies of my iPhoto library, since it is fairly