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.

Similar Messages

What is the best practice for creating primary key on fact table?

what is the best practice for primary key on fact table?
1. Using composite key
2. Create a surrogate key
3. No primary key
In document, i can only find "From a modeling standpoint, the primary key of the fact table is usually a composite key that is made up of all of its foreign keys."
http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/logical.htm#i1006423
I also found a relevant thread states that primary key on fact table is necessary.
Primary Key on Fact Table.
But, if no business requires the uniqueness of the records and there is no materilized view, do we still need primary key? is there any other bad affect if there is no primary key on fact table? and any benifits from not creating primary key?

Well, natural combination of dimensions connected to the fact would be a natural primary key and it would be composite.
Having an artificial PK might simplify things a bit.
Having no PK leads to a major mess. Fact should represent a business transaction, or some general event. If you're loading data you want to be able to identify the records that are processed. Also without PK if you forget to make an unique key the access to this fact table will be slow. Plus, having no PK will mean that if you want to used different tools, like Data Modeller in Jbuilder or OWB insert / update functionality it won't function, since there's no PK. Defining a PK for every table is a good practice. Not defining PK is asking for a load of problems, from performance to functionality and data quality.
Edited by: Cortanamo on 16.12.2010 07:12

Duplicate record with same primary key in Fact table

Hi all,
Can the fact table have duplicate record with same primary key . When i checked a cube i could see records with same primary key combination but the key figure values are different. My cube has 6 dimentions (Including Time,Unit and DP) and 2 key figures. So 6 fields combined to form the composite primary key of the fact table. When i checked the records in se16 i could see duplicate records with same primary key. Ther are no parallel loading happening for the cube.
BW system version is 3.1
Data base is : Oracle 10.2
I am not sure how is this possible.
Regards,
PM

Hi Krish,
I checked the datapacket dimention also. Both the record have same dimention id (141). Except the Keyfigure value there is no other change in the Fact table record. I know this is against the basic DBMS primary key rule. But i have records like this in the cube.
Can this situation arise when same records is there in different data packet of same request.
Thx,
PM
null

Distinct count of dimension business key in fact table

In my cube I have a fact table which joins to a patient dimension. The patient dimension is a type 2. What I would like to do is get a distinct count of patients who have records in the fact table. The business key in the patient dimension
is the PrimaryMrn. So a SQL query would look like this.
SELECT count(distinct PrimaryMrn)
FROM EncounterFact e
INNER JOIN PatientDim p
on e.PatientKey = p.PatientKey
Is it possible to do this via MDX?
Thanks for the help.

If you have to distinct count an attribute in a SCD 2, you might choose between:
Denormalizing that attribute in the fact table, and the create a classical DISTINCT COUNT measure
Use a many-to-many approach - see the "Distinct Count" scenario in the Many-to-Many White paper here:
http://www.sqlbi.com/articles/many2many (for both Multidimensional and Tabular
If you use Tabular, you might want to read also this pattern:
http://www.daxpatterns.com/distinct-count/
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

Primary key in Fact table

Hi ,
I have a question usually fact table consists of all primary keys from different dimensional tables but i have a requirement like this:
Fact table consists of non-dimensional columns and one primary key Amount_ID(PK) aand this amount_ID is a FK in another table which records day to day transactions. My question is can a fact table have a PK ?
Thanks,
ch

Yes Fact Table can have a Primary key
But in your case it looks like the Other Table which is storing Day to Day transaction should be made FACT , and the one you are calling FACT should be made Dimension..
Well depends again, how you are analysing data and against which attributes
Thanks
Ashish

Primary key in fact/Dimention/SID table?

Hello sap gurus,
2 Questions....
Which is primary key in
-Fact table (probably answer is .... combination of DIM_ID keys)
-Dimention table ( probably answer is .... DIM_ID key)
-SID table ( probably answer is .... SID_ID key)
Thnx in advance

Gaurav,
You already have the answers. A very simple way to figure out the keys is to use the transaction LISTSCHEMA, it will list the tables in an Infocube. Once you have the tables , you can use se11/se12 to check the keys.
For ODS information in BI 7, check the link below.
http://help.sap.com/saphelp_nw70/helpdata/en/80/1a60cae07211d2acb80000e829fbfe/frameset.htm
For ODS information in BW 3.5 , check the link below
http://help.sap.com/saphelp_nw04/helpdata/en/c0/99663b3e916a78e10000000a11402f/frameset.htm
-Saket

OBIEE 11g: Fact table does not have a properly defined primary key

Hi,
We have two fact tables and two dimension tables.
We have joined the tables like
D1-->F1
D2-->F2
D1-->D2
We dont have any hieracies.
It is throwing error in consistency check,
[nQSError: 15001] Could not load navigation space for subject area ABC.
[nQSError: 15033] Logical table Fact1 does not have a properly defined primary key.
It is not like STAR Schema, its like snowflake schema. How to define primary key for fact table.
Thanks.

Hi,
My suggestion would be bring both the facts to the same logical table sources and have a single fact table in the BMM layer joined with multiple dimensions.
Build a dimension hierarchy for the dimensions and then in the content logical layer mapping, map the dimensions to the fact tables with detailed level/Total
Refer the below link-
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
Hope this help's
Thanks,
Satya

Creating fact Table in ODI

I just started working in ODI sometime back.
But getting problem while creating a fact table.
In datstore i am creating foreign keys(i.e Reference Key) for the fact table which have respective parent table and primary key.
but after executing the interface foreign key is not being created in the database.
Can anyone solve my problem for creating foreign key in fact table?
thanks
Gourisankar
Edited by: user10220907 on Oct 15, 2008 9:31 PM

Hi
My target Dimension:T_Comapany where Comp_SKEY is a Surrogate key which is mapped to a sequence.
My Fact Table :T_Fact_Sales where Company_Key is a column
My requirement is to map the T_Comapany.Comp_SKEY(Surrogate Key) to T_Fact_Sales.Company_Key(Foreign Key)
There are some other measures which i am mapping them in interface.
Can anyone explain the procedure how to map Surrogate KEY of a dimension table to fact table???
Thanks in advance
regards
Gourisankar
Edited by: user10220907 on Oct 29, 2008 10:06 PM

OBIA How to truncate all fact tables automatically before running a full load

With every run data gets appended to the fact tables.How to configure so that with every run data gets deleted before we start the load.
We have OBIA 11g

If you are using DAC for scheduling the ETL jobs, you can list out the fact tables that are being used in your execution plan and set the Refresh dates for those tables as NULL. This action makes the dac execution plan to consider loading the data freshly into the fact tables.
Steps to make Refresh date as NULL in DAC:
To make the refresh dates as NULL for your fact tables in DAC, go to Setup tab -> Physical Data Sources
Now select the connection Datawarehouse(In my case) -> Refresh Dates
Query your fact tables and go to Refresh Date column and click on the calendar Icon
Click on NULL button to make the refresh date as NULL for that particular table and click on ok and save.
In the similar manner do it for all the fact tables you want.
After the above process, once you run the execution plan then data will be loaded freshly.
Regards,
Obul

How to create solved fact table and corresponding cube

Hello,
I want to create cube with solved fact table. It means, i need to feed data for higher levels of dimension also from fact table instead of aggreting from base level.
I am using star schema and AWM 10g R2 for creating cube.
If anyone knows how to do this, i would be very benificial.
Thanks
Subash

I have generated parent child script using cwm2_olap_pc_transform.create_script. After running this generated script, it has created 3 table/view.
My Base Parent Child table is like this:-
drop table PARENT_CHILD;
create table PARENT_CHILD (PARENT varchar2(30), CHILD varchar2(30));
insert into PARENT_CHILD values ('Eligible', 'Compliant');
insert into PARENT_CHILD values ('Eligible', 'Non-Compliant');
insert into PARENT_CHILD values ('All', 'Eligible');
insert into PARENT_CHILD values ('All', 'Ineligible');
insert into PARENT_CHILD values (null, 'All');
After running generated script thru cwm2_olap_pc_transform.create_script, it has created :-
Table - PARENT_CHILD_SOLVED
View - PARENT_CHILD_SOLVED_view , PARENT_CHILD_view
This script also inserted data in above table/view. (5 rec in each). Table/View structure is like this:-
SQL> desc PARENT_CHILD_view
Name Null? Type
GID NUMBER
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 All Eligible Compliant
0 All Eligible Non-Compliant
1 All Eligible
1 All Ineligible
3 All
SQL> desc PARENT_CHILD_SOLVED
Name Null? Type
GID NUMBER
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 All Eligible Compliant
0 All Eligible Non-Compliant
1 All Eligible
1 All Ineligible
3 All
SQL> desc PARENT_CHILD_SOLVED_view
Name Null? Type
GID NUMBER
SHORT_DESCRIPTION VARCHAR2(30)
LONG_DESCRIPTION VARCHAR2(30)
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 Compliant Compliant All Eligible Compliant
0 Non-Compliant Non-Compliant All Eligible Non-Compliant
1 Eligible Eligible All Eligible
1 Ineligible Ineligible All Ineligible
3 All All All
I tried to create dim and cube based on this. I am not sure whether its correct or not! Though validate_dimension API call shows that it is valid.
Script for Dim:-
DECLARE
-- variable to hold error message
errtxt varchar(60);
BEGIN
-- To be on safer side just drop dimension before creating new one and catch exceptions
BEGIN
cwm2_olap_dimension.drop_dimension('APPS', 'HCP_DIM_PC');
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Dimension HCP_DIM_PC not dropped');
END;
cwm2_olap_dimension.create_dimension(
'APPS',
'HCP_DIM_PC',
'Parent Child',
NULL,
'Parent Child',
'Parent Child',
NULL);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Short Description',
'Short Description',
'Short Description',
'Short Description',
TRUE);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Long Description',
'Long Description',
'Long Description',
'Long Description',
TRUE);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'Grouping ID',
'Grouping ID',
'Grouping ID',
TRUE);
cwm2_olap_hierarchy.create_hierarchy(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'Standard',
'Standard',
'Standard Parent Child Hierarchy',
'SOLVED LEVEL-BASED');
cwm2_olap_dimension.SET_DEFAULT_DISPLAY_HIERARCHY ('APPS', 'HCP_DIM_PC', 'HCP_DIM_PC_HIER');
cwm2_olap_level.create_level(
'APPS',
'HCP_DIM_PC',
'ALL_PARENT_LVL',
'All Parent Child',
'All Parent Child',
'All Parent Child',
'All Parent Child Level');
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Short Description',
'ALL_PARENT_LVL',
'Short Description',
'Short Description',
'Short Description',
'Short Description',
TRUE);
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Long Description',
'ALL_PARENT_LVL',
'Long Description',
'Long Description',
'Long Description',
'Long Description',
TRUE);
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'ALL_PARENT_LVL',
'Grouping ID',
'Grouping ID',
'Grouping ID',
'HTB Grouping ID',
TRUE);
-- Add all levels one by one to dimension hierarchy. For top most level last parameter is null.
cwm2_olap_level.add_level_to_hierarchy(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
NULL);
BEGIN
cwm2_olap_table_map.removemap_dimtbl_hierlevel(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Short Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Short Description');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Long Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Long Description');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Grouping ID', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Grouping ID');
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Level map for ALL_PARENT_LVL not removed');
END;
-- Map ALL_PARENT_LVL level to dimension table. Last parameter is null since it is top most level
cwm2_olap_table_map.map_dimtbl_hierlevel(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'GID',
NULL);
-- one by one map all the level attributes to respective columns in the dimension table.
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Short Description',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Short Description',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'SHORT_DESCRIPTION');
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Long Description',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Long Description',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'LONG_DESCRIPTION');
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Grouping ID',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'GID');
-- Use cwm2_olap_validate.validate_dimension to validate the dimension
cwm2_olap_validate.validate_dimension('APPS', 'HCP_DIM_PC');
cwm2_olap_metadata_refresh.mr_refresh;
-- Rollback if any exception occurs during processing this script
EXCEPTION
WHEN OTHERS THEN
cwm_utility.dump_error;
errtxt := cwm_utility.get_last_error_description;
dbms_output.put_line('ERROR: ' || errtxt);
ROLLBACK;
RAISE;
END;
Script for Cube:-
declare
HCP_time_dim number;
errtxt varchar(60);
begin
cwm_utility.collect_garbage;
begin
cwm2_olap_cube.drop_cube('APPS', 'HCP_PC_CUBE');
exception
when others then
dbms_output.put_line('No HCP_PC_CUBE to drop');
end;
begin
cwm2_olap_catalog.drop_catalog('HCP_PC_CAT');
exception
when others then
dbms_output.put_line('No HCP_PC_CAT to drop');
end;
CWM2_OLAP_CUBE.Create_Cube('APPS', 'HCP_PC_CUBE', 'Parent Child Cube', 'Parent Child Cube','Parent Child Cube');
cwm2_olap_cube.add_dimension_to_cube('APPS', 'HCP_PC_CUBE','APPS', 'HCP_DIM_PC');
cwm2_olap_measure.create_measure('APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE', 'PC Measure','PC Measure', 'PC Measure Fact');
cwm2_olap_table_map.map_facttbl_levelkey('APPS','HCP_PC_CUBE','APPS','HCP_PC_FACT','ET', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:ALL_PARENT_LVL/COL:CHILD3;');
cwm2_olap_table_map.Map_FactTbl_Measure('APPS', 'HCP_PC_CUBE','HCP_PC_MEASURE', 'APPS', 'HCP_PC_FACT', 'MEASURE_COL', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:CHILD3/COL:SHORT_DESCRIPTION;');
cwm2_olap_catalog.create_catalog('HCP_PC_CAT', 'Parent Child Catalog');
cwm2_olap_catalog.add_catalog_entity('HCP_PC_CAT', 'APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE');
cwm2_olap_validate.validate_cube('APPS', 'HCP_PC_CUBE','DEFAULT','YES');
cwm2_olap_metadata_refresh.mr_refresh;
exception
when others then
cwm_utility.dump_error;
errtxt := cwm_utility.get_last_error_description;
dbms_output.put_line('ERROR: ' || errtxt);
rollback;
raise;
END;
My Fact Table is :-
DROP TABLE HCP_PC_FACT CASCADE CONSTRAINT;
CREATE TABLE HCP_PC_FACT (
SHORT_DESCRIPTION VARCHAR2(30) NOT NULL,
GID NUMBER NOT NULL,
CHILD1 VARCHAR2(30) NOT NULL,
CHILD2 VARCHAR2(30) ,
CHILD3 VARCHAR2(30) ,
MEASURE_COL NUMBER NOT NULL);
Data in Fact Table:-
insert into HCP_PC_FACT values('Compliant',0,'All','Eligible','Compliant', 100);
insert into HCP_PC_FACT values('Non-Compliant',0,'All','Eligible','Non-Compliant', 200);
insert into HCP_PC_FACT values('Eligible',1,'All','Eligible',null, 300);
insert into HCP_PC_FACT values('Ineligible',1,'All','Ineligible',null, 400);
insert into HCP_PC_FACT values('All',3,'All',null,null, 500);
I am not sure how to create level, level attr, dim attr for such dim.
All CWM2 validation API shows that my all dims, cubes are valid but when I try to create presentation thru JDev it hangs after selecting Parent-Child Measure.
Any complete working exapmle will be helpful.
P.S. One more query I have can we have one solved and one un-solved dim in the same cube/measure?
regds
Prakash

Dimension table and fact table exists data physically

Hi experts,
can anyone plz tell me weather dimension table and fact table exists data physically or not/

Hi..Sudheer
SAPu2019s BW is based on "Enhanced Star schema" or "Info Cubes" database design.This database design has a central database table, known as u2018Fact Tableu2019 which is surrounded by associated dimension tables.
Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains
millions to billions of records.
These dimension tables doesn't contain data it contain references to the pointer tables that point to the master data tables which in turn contain Master data objects such as customer, material and destination country stored in BW as Info objects. An InfoObjects can contain single field definitions such as transaction data or complex Customer Master Data that hold attributes, hierarchy and customer texts that are stored in their own tables.
SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO. In SAP BW star schema, the distinction is made between two self contained areas: Infocube & master data tables/SID tables.
The master data doesn't reside in the satr schema but resides in separate tables which are shared across all the star schemas in SAP BW. A numer ID is generated which connects the dimension tables of the infocube to that of the master data tables.
The dimension tables contain the dim ID and SID of a particular IO. Using this SID the attributes and texts of an master data Io is accessed.
The SID table is connected to the associated master data tables via teh char key.
Fact table(Transaction data,DIM ID)<>Dimention Table(SID and Dim ID)<->Masterdata table(SID,IO)
Thanks,
Abha

OOTB Fact table contains Employee detailed Dates

Hi Experts,
we Have 4 date columns (pos_entry_dt, grade_entry_dt etc) in HR Fact out of Box fact table(W_WRKFC_EVT_MONTH_F_SNAPSHOT) which are not populated into presentation layer or BMM Layer and is not linked with day dimension. but the dates are needed when users want detailed level reports. as i know, we can not populate dates directly because BI Server assumes them as facts. i tried to created a separate table with only four columns and achieve this...but it will not work as duplicates will come into picture.
what will be the best way to populate this into Presentation layer
is it okay to populate them from Fact table itself? or its good to create as separate dimension
Thanks
Kumar

Hi Turri
thank you
I Can not create a join with day dimension because there is no key from fact table that can explicitly make a join with Day dimension to get this column from DAY Dimension table. its all out of box and if i have to create a key its a lot customization
for example:
I have
event_month_wid and job_entry_dt in fact table
200704     22-DEC-00
200705     22-DEC-00
200710     22-DEC-00
200711     22-DEC-00
200805     22-DEC-00
200806     22-DEC-00
200807     22-DEC-00
200810     01-OCT-08
200811     01-OCT-08
200812     01-OCT-08
200901     01-OCT-08
200902     01-OCT-08
200907     01-OCT-08
and in Day dimension table
ROW_WID CALENDER DATE
20090720     20-JUL-09
20090719     19-JUL-09
20090718     18-JUL-09
20090717     17-JUL-09
20090716     16-JUL-09
20090715     15-JUL-09
20090714     14-JUL-09
if i make join between them, i will get different dates
Please suggest any ideas?
Thank you
Kumar

Multiple Query / Fact Table question

I'm a bit new to obiee, and am trying to accomplish something that should be pretty easy.
Here is my basic table structure:
Month table (dimension)
Month Key (primary Key)
aTable (fact table)
MonthKey
NameA
totalA
bTable (fact table)
MonthKey
totalB
The goal of the report is (4 columns):
MonthKey, NameA, and totalA.
The final Column should be TotalA / TotalB
I have 2 subject areas, but since they are related I can use them together.
The problem I'm running into is that TotalB basically becomes TotalA (which it shouldn't) because of the inclusion of "NameA" from aTable.
Any ideas? Is there a way to compare queries like this, when they are not necessarily related?

Ok, behavior is different but EVENT_NO column always store the value 1, so the final result at the report is the same.
I'm interesting to know the total events by month, department and event type.
Each record at fact table represent only one event, so I can query with SUM or COUNT statment because the result is the same, but ... the performance?
Thanks

Surrogate key for fact

Hi all,
i don't know that in ETL update of existing records in fact can happen or not. IF it happen then how can i handle it? is it recommendable to implement surrogate key for fact tables to update the existing records of fact? That work like primary key for fact table. This doesn't have any relation with OWB. This is a general concept about ETL.
Regards,
Sumanta

Yes, you can update a fact.
You generally do this by adding a unique constraint to the fact table which comprises the identifying primary key columns from the source tables, but exclusive of the surrogate key. The surrogate key will be the actual primary key of the table.
Now, when you make an insert/update mapping you include a sequence that generates your surrogate key, and then select the 'match by' on the fact table to match by the unique key (actual source table values which determine uniqueness) rather than the primary key. Then, on the surrogate key column on the fact table which is being populated by the sequence, you set its property to not update the surrogate key when an update is being applied to the row.
This way the update statement will not update the surrogate key when updating the fact based upon the source identifiers that identify this fact.
I'm sure I could explain this more clearly... but I'm very pressed for time right now.
Cheers,
Mike

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

Null key in fact tables

Similar Messages

Maybe you are looking for