Populating Fact tables

Hi,
First time working on DW. Have got my staging and Dimension table setups.
About to start working on Fact tables and all examples I see online are using SSIS packages with several lookup tables.
Is there any reason that this cannot be done using Stored procedure or I have to develop SSIS package to populate fact tables.
Thanks,

Hello,
In fact we are using stored procedure for all our manipulations and populating fact table. The fact table is partitioned and works great with no issues.
We are calling the stored procedure and PL/SQL procedure from Informatica. I don't find any issue in processing but I feel difficulty in debugging 5000 lines of code.
If the transformation are simple and it can be handle in stored procedure than you can go for it But SSIS is designed for ETL. 
In considering maintenance overhead SSIS gives better control over the data flow because business logic and debugging is much easier than doing the same in stored procedure. 
If you've partitions and properly designed data structures definitely you can think of using SP. 
-Prashanth

Similar Messages

  • DAC not populating FACT table for the GL module - W_GL_OTHER_F (zero rows)

    All - We did our FULL loads from the Oracle Financials 11i into OBAW and got data in most of the dimension tables populated. HOWEVER, i am not seeing anything populating into the fact table W_GL_OTHER_F (zero rows). Following is a list of all dims / facts i am focusing towards for the GL module.
    W_BUSN_LOCATION_D     (8)
    W_COST_CENTER_D     (124)
    W_CUSTOMER_FIN_PROFL_D     (6,046)
    W_CUSTOMER_LOC_D     (4,611)
    W_CUSTOMER_LOC_D     (4,611)
    W_CUSTOMER_LOC_D     (4,611)
    W_DAY_D     (11,627)
    W_DAY_D     (11,627)
    W_DAY_D     (11,627)
    W_GL_ACCOUNT_D     (28,721)
    W_INT_ORG_D     (171)
    W_INVENTORY_PRODUCT_D     (395)
    W_LEDGER_D     (8)
    W_ORG_D     (3,364)
    W_PRODUCT_D     (21)
    W_PROFIT_CENTER_D     (23)
    W_SALES_PRODUCT_D     (395)
    W_STATUS_D     (7)
    W_SUPPLIER_D     (6,204)
    W_SUPPLIER_PRODUCT_D     (0)
    W_TREASURY_SYMBOL_D     (0)
    W_GL_OTHER_F <------------------------------------- NO FACT DATA AT ALL
    Question for the group: Are there any specific settings which might be preventing us from getting data loaded into our FACT tables? I was doing research and found the following on the internet:
    Map Oracle General Ledger account numbers to Group Account Numbers using the following file file_group_acct_names_ora.csv. Is this something that is necessary?
    Any help / guidance / pointers are greatly appreciated.
    Regards,

    There are many things to configure before your first full load.
    For the configuartion steps see Oracle Business Intelligence Applications Configuration Guide for Informatica PowerCenter Users
    - http://download.oracle.com/docs/cd/E13697_01/doc/bia.795/e13766.pdf (7951)
    - http://download.oracle.com/docs/cd/E14223_01/bia.796/e14216.pdf (796)
    3 Configuring Common Areas and Dimensions
    3.1 Source-Independent Configuration Steps
    Section 3.1.1, "How to Configure Initial Extract Date"
    Section 3.1.2, "How to Configure Global Currencies"
    Section 3.1.3, "How to Configure Exchange Rate Types"
    Section 3.1.4, "How to Configure Fiscal Calendars"
    3.2 Oracle EBS-Specific Configuration Steps
    Section 3.2.1, "Configuration Required Before a Full Load for Oracle EBS"
    Section 3.2.1.1, "Configuration of Product Hierarchy (Except for GL, HR Modules)"
    Section 3.2.1.2, "How to Assign UNSPSC Codes to Products"
    Section 3.2.1.3, "How to Configure the Master Inventory Organization in Product Dimension Extract for Oracle 11i Adapter (Except for GL & HR Modules)"
    Section 3.2.1.4, "How to Map Oracle GL Natural Accounts to Group Account Numbers"
    Section 3.2.1.5, "How to make corrections to the Group Account Number Configuration"
    Section 3.2.1.6, "About Configuring GL Account Hierarchies"
    Section 3.2.1.7, "How to set up the Geography Dimension for Oracle EBS"
    Section 3.2.2, "Configuration Steps for Controlling Your Data Set for Oracle EBS"
    Section 3.2.2.1, "How to Configure the Country Region and State Region Name"
    Section 3.2.2.2, "How to Configure the State Name"
    Section 3.2.2.3, "How to Configure the Country Name"
    Section 3.2.2.4, "How to Configure the Make-Buy Indicator"
    Section 3.2.2.5, "How to Configure Country Codes"
    5.2 Configuration Required Before a Full Load for Financial Analytics
    Section 5.2.1, "Configuration Steps for Financial Analytics for All Source Systems"
    Section 5.2.2, "Configuration Steps for Financial Analytics for Oracle EBS"
    Section 5.2.2.1, "About Configuring Domain Values and CSV Worksheet Files for Oracle Financial Analytics"
    Section 5.2.2.2, "How to Configure Transaction Types for Oracle General Ledger and Profitability Analytics (for Oracle EBS R12)"
    Section 5.2.2.3, "How to Configure Transaction Types for Oracle General Ledger and Profitability Analytics (for Oracle EBS R11i)"
    Section 5.2.2.4, "How to Specify the Ledger or Set of Books for which GL Data is Extracted"
    5.3 Configuration Steps for Controlling Your Data Set
    Section 5.3.1, "Configuration Steps for Financial Analytics for All Source Systems"
    Section 5.3.2, "Configuration Steps for Financial Analytics for Oracle EBS"
    Section 5.3.2.1, "How GL Balances Are Populated in Oracle EBS"
    Section 5.3.2.2, "How to Configure Oracle Profitability Analytics Transaction Extracts"
    Section 5.3.2.3, "How to Configure Cost Of Goods Extract (for Oracle EBS 11i)"
    Section 5.3.2.4, "How to Configure AP Balance ID for Oracle Payables Analytics"
    Section 5.3.2.5, "How to Configure AR Balance ID for Oracle Receivables Analytics and Oracle General Ledger and Profitability Analytics"
    Section 5.3.2.6, "How to Configure the AR Adjustments Extract for Oracle Receivables Analytics"
    Section 5.3.2.7, "How to Configure the AR Schedules Extract"
    Section 5.3.2.8, "How to Configure the AR Cash Receipt Application Extract for Oracle Receivables Analytics"
    Section 5.3.2.9, "How to Configure the AR Credit-Memo Application Extract for Oracle Receivables Analytics"
    Section 5.3.2.10, "How to Enable Project Analytics Integration with Financial Subject Areas"
    Also, another reason I had was that if you choose not to filter by set of books/type then you must still include the default values set of books id 1 and type NONE in the list on the DAC parameters (this is a consequence of strange logic in the decode statements for the sql in the extract etl).
    I would recomend you run the extract fact sql prior to running your execution plan to sanity check how many rows you expect to get. For example, to see how many journal lines, use informatica designer to view mapplet SDE_ORA11510_Adaptor.mplt_BC_ORA_GLXactsJournalsExtract.2.SQ_GL_JE_LINES.3 in mapping SDE_ORA11510_Adaptor.SDE_ORA_GLJournals then cut paste the SQL to run your favourite tool such as sqldeveloper. You will have to fill in the $$ variables yourself.

  • Populating Fact and Dimension Tables

    Hi there,
    New to OLAP. I've defined my schema design and would like to start population my dimension tables along with the foreign key references in my fact tables to my dimension tables.
    Before I begin writing a bunch of PL/SQL scripts to do this. I am wondering if any tools exist to help expedite this type of process.
    As a start I will be linking my fact table to two dimensions. One being a standard date dimension, the other being a user dimension consisting of hours and minutes. Any examples, links would be greatly appreciated.
    Thanks!

    Hi Chandra, it would be useful if you read a little bit about BI before start working with a BI tool.
    Anyway, I'll try to help you.
    A dimension is a structure that will be join to the fact table to so that users can analyze data from different point of views and levels. The fact table will most probably (not always) have data at the lowest possible level. So, let's suppose you have SALES data for different cities in a country (USA). Your fact table will be:
    CITY --- SalesValue
    Miami --- 100
    NYC --- 145
    Los Angeles --- 135 (because Arnold is not managing the State very well ;-) )
    You will then can have a Dimension table with the "Country" structure. This is, a table containing the different cities along with their states, counties, and finally the country. So your dimension table would look like:
    NATION --- STATE --- COUNTY --- CITY
    USA --- Florida --- Miami --- Miami
    USA --- NY ---- NY --- NYC
    USA --- Los Angeles --- LA --- Los Angeles
    This dimension will allow you to aggregate the data at dffirent lavels. This is, the user will not only be able to see data at the lowest level, but also at the County, State and Country level.
    You will join your fact table (field CITY) with your dimension table (field CITY). The tool will then help you with the aggregation of the values.
    Ihope this helps.
    J.-

  • Problem with populating a fact table from dimension tables

    my aim is there are 5 dimensional tables that are created
    Student->s_id primary key,upn(unique pupil no),name
    Grade->g_id primary key,grade,exam_level,values
    Subject->sb_id primary key,subjectid,subname
    School->sc_id primary key,schoolno,school_name
    year->y_id primary key,year(like 2008)
    s_id,g_id,sb_id,sc_id,y_id are sequences
    select * from student;
    S_ID UPN FNAME COMMONNAME GENDER DOB
    ==============================
    9062 1027 MELISSA ANNE       f  13-OCT-81
    9000 rows selected
    select * from grade;
          G_ID GRADE      E_LEVEL         VALUE
            73 A          a                 120
            74 B          a                 100
            75 C          a                  80
            76 D          a                  60
            77 E          a                  40
            78 F          a                  20
            79 U          a                   0
            80 X          a                   0
    18 rows selectedThese are basically the dimensional views
    Now according to the specification given, need to create a fact table as facts_table which contains all the dim tables primary keys as foreign keys in it.
    The problem is when i say,I am going to consider a smaller example than the actual no of dimension tables 5 lets say there are 2 dim tables student,grade with s_id,g_id as p key.
    create materialized view facts_table(s_id,g_id)
    as
    select  s.s_id,g.g_id
    from   (select distinct s_id from student)s
    ,         (select distinct g_id from grade)gThis results in massive duplication as there is no join between the two tables.But basically there are no common things between the two tables to join,how to solve it?
    Consider it when i do it for 5 tables the amount of duplication being involved, thats why there is not enough tablespace.
    I was hoping if there is no other way then create a fact table with just one column initially
    create materialized view facts_table(s_id)
    as
    select s_id
    from student;then
    alter materialized view facts_table add column g_id number;Then populate this g_id column by fetching all the g_id values from the grade table using some sort of loop even though we should not use pl/sql i dont know if this works?
    Any suggestions.

    Basically your quite right to say that without any logical common columns between the dimension tables it will produce results that every student studied every sibject and got every grade and its very rubbish,
    I am confused at to whether the dimension tables can contain duplicated columns i.e column like upn(unique pupil no) i will also copy in another table so that when writing queries a join can be placed. i dont know whether thats right
    These are the required queries from the star schema
    Design a conformed star schema which will support the following queries:
    a. For each year give the actual number of students entered for at A-level in the whole country / in each LEA / in each school.
    b. For each A-level subject, and for each year, give the percentage of students who gained each grade.
    c. For the most recent 3 years, show the 5 most popular A-level subjects in that year over the whole country (measure popularity as the number of entries for that subject as a percentage of the total number of exam entries).
    I written the queries earlier based on dimesnion tables which were highly duplicated they were like
    student
    =======
    upn
    school
    school
    ======
    school(this column substr gives lea,school and the whole is country)
    id(id of school)
    student_group
    =============
    upn(unique pupil no)
    gid(group id)
    grade
    year_col
    ========
    year
    sid(subject id)
    gid(group id)
    exam_level
    id(school id)
    grades_list
    ===========
    exam_level
    grade
    value
    subject
    ========
    sid
    subject
    compulsory
    These were the dimension table si created earlier and as you can see many columns are duplicated in other tables like upn and this structure effectively gets the data out of the schema as there are common column upon which we can link
    But a collegue suggested that these dimension tables are wrong and they should not be this way and should not contain dupliated columns.
    select      distinct count(s.upn) as st_count
    ,     y.year
    ,     c.sn
    from      student_info s
    ,     student_group sg
    ,     year_col y
    ,     subject sb
    ,     grades_list g
    ,     country c
    where      s.upn=sg.upn
    and     sb.sid=y.sid
    and     sg.gid=y.gid
    and     c.id=y.id
    and     c.id=s.school
    and      y.exam_lev=g.exam_level
    and      g.exam_level='a'
    group by y.year,c.sn
    order by y.year;This is the code for the 1st query
    I am confused now which structure is right.Are my earlier dimension tables which i am describing here or the new dimension tables which i explained above are right.
    If what i am describing now is right i mean the dimension tables and the columns are allright then i just need to create a fact table with foreign keys of all the dimension tables.

  • OBI Apps Data Not Populated on Fact tables

    Hi,
    I have installed Oracle BI Applications with Oracle DB 10.2.0.1, DAC 10.1.3.4.1, OBI Applications 7.9.6, Informatica 8.6 Adapters and OBIEE 10.1.3.4.1.
    I did the Initial load using DAC for Oracle EBS R12 (General Ledger and Payables) and after that when i checked the data, the data were not available on the Fact tables.
    While during Initial load some of the maps shown status as stopped.
    Did i misssed out some thing?
    Can i go to Informatica and try to rerun those (Stopped) maps again.?
    What is the reason for this problem..?
    Any suggestions appreciated.
    Thanks,
    Vino..

    Please move this question to the BI Apps Forum: Business Intelligence Applications
    Cheers,
    Christi@n

  • 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

  • Load fact table with null dimension keys

    Dear All,
    We have OWB 10g R2 and ROLAP star schema. In our source system some rows don’t have all attributes populated with values (null value), and this empty attributes are dimension (business) keys in star schema. Is it possible to load fact table with such rows (some dimension keys are null) in the OWB mappings? We use cube operator in mappings.
    Thanks And Regards
    Miran

    The dimension should have a row indicating UNKNOWN, this will have a business key outside of the normal range e.g. -999999.
    In the mapping the missing business keys can then be NVL'd to -999999.
    Cheers
    Si

  • Transaction data can be loaded into the Fact table without loading the

    Transaction data can be loaded into the Fact table without loading the corresponding master data (Example : Sales analysis transaction data can be loaded without populating any of its  dimension’s master data)
    a.     True
    b.     False

    Hi Kutti,
    True - You need to select the option in the infopackage - alwyas load even if no master data exists.
    Bye
    Dinesh

  • How to set db schema in fact tables

    Hi!
    I have one mapping with one table(table1) pointing to one fact table (fact1).
    This fact table has two dimensions located in two different schemas. I already deployed those dimensions and tables and its ok.
    My problem is: when I open the mapping editor and ask to generate the mapping to create the package to populate the fact table,
    I can see why I can not deploy it (PL/SQL: ORA-00942: table or view does not exist).
    My query is: SELECT (fields) FROM schema.table1, table2 ,table3 WHERE....
    I cant set the schema property from my table (table1), but I cant´t do the same with the table2 and table3 (both tables related to dimensions). i don´t have this option!
    I don´t understand why this happen because both dimensions are ok. They are in two different modules and the locations are ok too.
    I understand that the mapping needs the dimension keys to populated the fact table, but I really don´t know how to set this schema property. If i can´t do that,
    i don´t know how to "fix" this problem. If a can´t set this schema property, how can I deploy this mapping whitout this???!!!!
    I´m using the 10.2 version.
    Thanks o lot!!!!!!!!!!!

    This is what really happens in my example.
    Look the "Generation Results" :
    SELECT
    /*+ ORDERED NO_MERGE("INGRP1") */
    "TEMP_TABLE"."Value1" "Value1",
    "TEMP_TABLE"."Value2" "Value2",
    "DIMENSION1"."ID" "ID",
    "DIMENSION2"."ID" "ID"
    FROM
    "SCHEMA"."TEMP_TABLE" "TEMP_TABLE", -> I CANT SET THIS schema
    "DIMENSION1" "DIMENSION1", -> i can´t do the same here
    "DIMENSION2" "DIMENSION2" -> i can´t do the same here
    WHERE
    ( "DIMENSION1"."DIMENSION_KEY" = "DIMENSION1"."ID" ) AND
    ( "DIMENSION1"."ID" IS NOT NULL ) AND
    ( "DIMENSION2"."DIMENSION_KEY" = "DIMENSION2"."ID" ) AND
    ( "DIMENSION2"."ID" IS NOT NULL ) AND
    ( "DIMENSION1"."key" = "TEMP_TABLE"."key" ) AND
    ( "DIMENSION2"."key" = "TEMP_TABLE"."key" )
    I already tried to use 3 DB-Modules but I have the same problem. :o(
    I don´t know what to do!!!!!!!

  • Issue with non calculated column in a fact table

    Hi All,
    With 3 facts(Fact1,Fact2,Fact3) and 2 Confirmed Dimensions my joins work fine in Criteria when I include All calculated columns from facts. If I try to include a non calculated column from Fact1(Which is a number Data type) Columns from Fact2 and Fact3 show Null values. I know it is not recommended to include dimension columns in fact , does OBIEE not support Number type non calculated columns as well? Is there any work around that I can bring in my non calculated column from Fact and still get results for other fact columns.Iam at 11.1.1.7 of OBIEE
    Let me know if Iam not clear.
    Your help is much Appreciated.
    Thanks,
    Vineela.

    i would like to add 2 fields into my fact tables - LOAD ID (populated by a sequence during each load) and LOAD DATE.
    as these fields are not related to any reporting dimensions, it is still possible to add them in OWB ? the fact wizard always ask for a foreign key to a dimension ...
    Duncan,
    If you want to add non dimensional attributes to a fact by using OWB, you can create additional measures to it and use them as attributes.
    Igor

  • Non dimensional attributes in a fact table

    i would like to add 2 fields into my fact tables - LOAD ID (populated by a sequence during each load) and LOAD DATE.
    as these fields are not related to any reporting dimensions, it is still possible to add them in OWB ? the fact wizard always ask for a foreign key to a dimension ...

    i would like to add 2 fields into my fact tables - LOAD ID (populated by a sequence during each load) and LOAD DATE.
    as these fields are not related to any reporting dimensions, it is still possible to add them in OWB ? the fact wizard always ask for a foreign key to a dimension ...
    Duncan,
    If you want to add non dimensional attributes to a fact by using OWB, you can create additional measures to it and use them as attributes.
    Igor

  • Confirmed Dimensions. OBIEE Not able to pull data from two fact tables.

    Hi Experts,
    I have a very simple set up of Star Schema with two fact tables and 1 dimension. Both fact tables joined to the dimension at the same level.
    When i pull a column from both fact tables and the dimension table in OBIEE, it has to create simple SQL like below:
    select FACT1.column1,
    Fact2.Column1,
    Dim.Column1
    from FACT1, FACT2, DIM
    where FACT1.ID = DIM.ID and FACT2.ID = DIM.ID
    but instead it creating a query in a very complex way:
    select case  when D1.c2 is not null then D1.c2 when D2.c2 is not null then D2.c2 end  as c2,
         D1.c1 as c3,
         D2.c1 as c4
    from
         (select FACT1.Column1 as c1,
                   DIM.Column1 as c2
              from
                   DIM T1287863,              
                   FACT1 T1287945              
       where  (DIM.ID = FACT1.ID)
           ) D1 full outer join (
            select FACT2.Column1 as c1,
                   DIM.Column1 as c2
              from
                   DIM,              
                   FACT2
              where  ( DIM.ID = FACT2.ID)
         ) D2 On isnull(D1.c2 , '1') = isnull(D2.c2 , '1') and isnull(D1.c2 , '2') = isnull(D2.c2 , '2')
    I even tried setting the levels for both the fact tables and it still creates the query in avove way. Any thoughts on this will be vary helpful.

    Subramanian,
    see below the code we're using for the RFM.
    on the ct_containers table i'm passing a line, and its getting updated after the call.
    on the ct_errors table i just want to receive the errors and i only receive the line, we add manually there ('Serious error with validation code').
    kr, achim
    FUNCTION zbapi_ra_validations .
    *"*"Local Interface:
    *"  IMPORTING
    *"     VALUE(IS_RA_SCREEN) TYPE  ZBAPI_S_RA_SCREEN
    *"  CHANGING
    *"     VALUE(CT_ERRORS) TYPE  ZRA_T_ERRORS
    *"     VALUE(CT_CONTAINERS) TYPE  ZRA_T_CONT_IP
      DATA:
        lo_badi_handle TYPE REF TO zra_validation_rule,
        ls_error       TYPE zra_s_error.
      GET BADI lo_badi_handle.
      TRY.
          CALL BADI lo_badi_handle->validate_rules
            EXPORTING
              is_screen_flds = is_ra_screen
            CHANGING
              ct_containers  = ct_containers
              ct_errors      = ct_errors.
        CATCH zcx_ra.
          ls_error-message = 'Serious error with validation code'.
          APPEND ls_error TO ct_errors.
      ENDTRY.
    ENDFUNCTION.
    if i call this rfm in SE37 the ct_errors table is populated with all errors and the manually created line.
    Message was edited by: Achim Hauck

  • Insert data into fact table from source database tables

    here i try to insert data into fact table from source database tables here is the query 
    ALTER procedure [dbo].[facttable]
    as
    insert into [pp dw].dbo.Dimfact(Prod_ID,Production_ID,Material_ID,Equip_ID,WC_ID,Recipe_ID,Quantity,costprice)
    select Products.[Product ID],[Production ID],Materials.[Material ID],[Equipment ID],[Work Centre ID],[Recipy ID],Quantity,[cost price]
    from
    [PRODUCTION PLANNING 2].dbo.[Products],
    [PRODUCTION PLANNING 2].dbo.[Production Detail],
    [PRODUCTION PLANNING 2].dbo.[Material category],
    [PRODUCTION PLANNING 2].dbo.[Materials],
    [PRODUCTION PLANNING 2].dbo.[Equipment],
    [PRODUCTION PLANNING 2].dbo.[Working Centre] ,
    [PRODUCTION PLANNING 2].dbo.[Recipies]
    where
    Products.[Product ID] in (13, 14, 15, 16, 17) and
    [Production Detail].[Production ID] in (1, 2, 3) and
    [Materials].[Material ID] in (1, 2, 3, 4, 5) and
    [Equipment].[Equipment ID] in (1, 2, 3, 4) and
    [Working Centre].[Work Centre ID] in (1, 2, 3) and
    [Recipies].[Recipy ID] in (1, 2, 3) and
    [Material category].[Category ID] in (8, 9, 10, 11, 12, 13)
    and when i execute query it shows me error 
    The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Dimfact_Dimproduct". The conflict occurred in database "pp dw", table "dbo.Dimproduct", column 'Prod_ID'.
    ERD IS
    HOW TO SOLVE THIS PROBLEM?

    I cant see any join conditions in your query posted. Whats the purpose of the query above. It will just bring you a cartesian product (cross join) of tables involved subjected to filters. Are you sure this is the correct query?
    The error you're getting may be because you've not yet populated DimProduct or may be because of logic you used in popultaing DimProduct causing it to miss some records which is what query is referring to in above case.
    Please Mark This As Answer if it solved your issue
    Please Mark This As Helpful if it helps to solve your issue
    Visakh
    My MSDN Page
    My Personal Blog
    My Facebook Page

  • Load data from dimensions to fact table

    Hi,
    I have 10 dimension tables and one fact table. now i want to load data in to fact table from dimensions table. how i can do that.
    Regards,
    joy

    To elaborate on "Mallee"'s answer, it's not good practice to load dimensional data into a fact table.
    I guess what you mean is how to refer to dimensions when loading a fact table.
    Simply refer to dimensions using lookups on the necessary dimensions, the lookup needs to be on the natural key you have that links facts to dimensions. Don't forget to use the dimension's surrogate key though when populating the fact table's foreign key columns pointing at the dimensions.
    Hope this helps.
    Cheers, Patrick

  • Understanding Fact Tables

    Hi,
    I am new to OBIEE, I have created several dimensions but am a little confused with fact tables and measures. I have a fact table already populated in the database containing dimension keys per each dimension, 3 measures. There are some additional columns(agreement_code, agreement_type, schedule_number). These additional columns do not link to the dimensions. Do these columns have to be included in the fact table inside the OBIEE BM layer or could they be removed. My question is does the fact table have to contain only measures or can there be other non-aggregated columns.
    Thanks

    Hi
    If I'm right, your 3 additionnal columns are attributs but they're in your fact table ?
    If so, they are "degenerated dimensions".
    If the end-user needs them, you will have to put them somewhere.
    You will create a new logical table based on the your physical fact table, but for dimension purpose.
    Actually, you will have :
    - 1 logical fact table, based on the physical fact table, and contains measures
    - 1 logical dim table, based on the same physical fact table, and logically linked to the logical fact table. It contains your 3 attributes.
    You can see a deeper explanation here, in my last post :
    Table as fact and dimension
    Note : you can also put the 3 columns in the logical fact table, it will works, but it's not the "propest" (not sure about this word... sorry, my english is not very good) method.

Maybe you are looking for