Creation of a Date Dimension Table

Is there an algorithm (PL/SQL or otherwise) out there somewhere that can be shared that I can use to create a Date Dimension so that I do not have to re-invent the wheel.
Thank you
Bob Spahn

Bob,
In the OWB 9.2, there is one sample mapping for time data creation; all you need to do is follow the instructions and use the code. This is part of your OWB client installation.
Path is {OWBHome}/owb/misc/time.
cheers
suresh

Similar Messages

Creation of address data in table ADR2(Vendor)

Hi all,
Please tell me a function nmodule to create adress data in table ADR2 .
Thanik

Hi,
Incase you want to change the details use the BAPI BAPI_ADDRESSPERS_CHANGE.
For a business partner the available BAPIs to add or change telephone number are
BAPI_BUPA_ADDRESS_ADD
BAPI_BUPA_ADDRESS_CHANGE.
Read the documentation of the bapis for further details.
Regards,
Ankur Parab

Creation of fact and dimension tables

Hi ETL Informatica Developer, We need not to create the Dimentions and Facts we need to Load the data only. We have to do calculations in The transforms for generating Dimentional records. And need to create mappings in which we need to Load the Facts with the combination of these Dimentions. Please go through the Basics of Star Schema and Snowflake Schema. Hope you can understand. Let me know if you want any help. Regards,DJ

That's a matter of policy.Does your organisation execute a strict differentiation between ETL developers and DBAs? Then it's probably up to the DBAs to set up the tables, but of course you have to tell them the structures of the tables that they shall create for you.Other organisations allow their ETL developers to create tables "on the fly" in development environments. If this the case for you, then it's up to you. If this is not what you wanted to know, could you please post your question differently so that we can clearly understand what you mean? Regards,Nico

Single date dimension while creating Aggregate tables

hi Guys ,
I have single date dimension(D1-D) with key as date_id and granularity is day-level. I have fact table(F1-D) which gives daily transactions . Now i created three aggregate tables with F2-M(aggregated to monthly),F3-Q(Aggregated to quarterly),F4-Y(Aggregated to yearly). As I said.I have a single date dimension table with date-id as a key.I have other columns month,quarter,year in Date dimension.
My question is : Is this single dimension table is enough to create the joins and maintain the BMM layer .I have joined the date_id to all the facts in physical layer. In BMM Layer i have one fact and 4 logical table sources .Ii have created dimension hierarchy on Date dimension and created the logical levels as year ,quarter,month and daily level and also set their respective level keys . Now after doing these i have also set the logical levels to the 4 logical table sources in the fact table.
Here i am getting an error saying :
WARNINGS:
BUSINESS MODEL Financial Model:
[39059] Logical dimension table D04_DIM_DATE has a source D04_DIM_DATE at level D04_DIM_DATE Detail that joins to a higher level fact source F02_FACT_GL_DLY_TRAN_BAL.F03_FACT_GL_PERIOD_TRAN_BAL
Can anyone tell me why am i getting this error .

1) as you suggest, creating mini dimension tables for each level
3) using views with select distinct x,y,z to model 1) but without the need for phsical tables
I have thought of these scenarios .But it's just creating a multiple Date Dimension tables with there respective grains if we follow 1 and 3 steps you mentioned.
But i don't want to create aliases or views either on Datawarehouse or physical layer (Admin tool).Just with using a single Date Dimension table I need to comeup with a solution as mentioned by my Colleagues.
2) pushing all the calendar attributes into the aggreate table (eg your year aggregate has all the year fields, your month aggregate has all the year fields and all the month fields etc.). Then in BM&M use the aggregate table as a logical table source for the date logical table.
What do you mean by "pushing all the calendar attributes into the aggreate table".If possible can you eloborate a bit so i can try in this way to get this done .
One morething .Here What they were saying is .Join the Single Date Dimension to all the 4 fact tables in Physical layer . Then drag all the tables into the BMM layer and create a Dimensional hierarchies for the Date dimension with levels as Year -->Quarter--> Month--> day level. With the Fact tables: Single fact tables with multiple logical table sources .Then we need to set the levels on the respective logical table sources with the desired levels .Say monthly aggregate table--> Month, Quarter Aggregate table--> quarter level in the Contents TAB.
When i do this I am getting the Warning:
WARNINGS:
BUSINESS MODEL Financial Model:
[39059] Logical dimension table D04_DIM_DATE has a source D04_DIM_DATE at level D04_DIM_DATE Detail that joins to a higher level fact source F02_FACT_GL_DLY_TRAN_BAL.F03_FACT_GL_PERIOD_TRAN_BAL

MDX query To get DateKey based on my Dimension table

Hi,
In my Date dimension table DateKey will be 1,2,3,4........
DateKey 1= 22nd Jan,2010
DateKey 2= 23rd Jan,2010
DateKey 3= 24th Jan,2010.
Now i want to get Today date(Ex.22jan2014) and LastYearSameDay date(Ex.23jan2014) by using mdx query.
Can you please suggest me.
Sudhan

Hi Sudhan,
According to your description, you want to get Today date and LastYearSameDay date by using mdx query. In this case, you can use Now() function and DateAdd function to get the result. Here is a sample query for your reference.
WITH MEMBER Measures.Today AS vba!Now(), FORMAT_STRING="Short Date"
MEMBER Measures.Yesterday AS Dateadd("d",-1,Measures.Today), FORMAT_STRING="Short Date"
SELECT {Measures.Today,Measures.Yesterday} on 0
FROM
[Adventure Works]
Result:
Regards,
Charlie Liao
TechNet Community Support

How to show current date in a column of dimension table in ssas

Hi,
I have 2 dimension tables (ALLWORK and YOURWORK) and 1 measure table (STATS). In ALLWORK dim table, I have 4 columns, one of them is END_DATE. Based on END_DATE and current date I want to create a named calculation field. To achieve this, I
want to show the current date in 5th column (of ALLWORK dim table) as calculated member (as named calculation wont show me correct date).
Problem is, I am not able to create the column in the dimension table. While creating the calculated member, I am not able to select the ALLWORK dimension table, it always selects MEASURE by default. Please help.
thanks
Tarique
thanks and regards Tarique Aslam

Hi Tarique,
According to your description, you want to add a column to your dimension to show the current date, right?
In data source view, we can add named calculation to your table. A named calculation is a SQL expression represented as a calculated column. This expression appears and behaves as a column in the table. A named calculation lets you extend the relational
schema of existing tables or views in a data source view without modifying the tables or views in the underlying data source.
Reference
http://msdn.microsoft.com/en-in/library/ms174859.aspx
http://devmau5.wordpress.com/2010/03/25/the-getdate-of-mdx/
If I have anything misunderstand, please point it out.
Regards,
Charlie Liao
TechNet Community Support

Dimension Table populating data

Hi
I am in the process of creating a data mart with a star schema.
The star schema has been defined with the fact and dimension tables and the primary and foreign keys.
I have written the script for one of the dimensions and would like to know when the job runs on a daily basis should the job truncate the table every day and rebuild the dimension table or should it only add new records to the table. If it should add only
new records to the table how do is this done?
I assume that the fact table job is run once a day and only new data is added to it?
Thanks

It will depend on the volume of your dimensions. In most of our projects, we do not truncate, we update only updated rows based on a fingerprint (to make the comparison faster than column by column), and insert for new rows (SCD1). For SCD2 we apply
similar approach for updates and inserts, and expirations in batch (one UPDATE for all applicable rows at the end of the package/ETL).
If your dimension is very large, you can consider truncating all data or deleting only affected modified rows (based on nosiness key) to later reload those, but you have to be carefully maintaining the same surrogate keys reference by your
existing facts.
HTH,
Please, mark this post as Answer if this helps you to solve your question/problem.
Alan Koo | "Microsoft Business Intelligence and more..."
http://www.alankoo.com

Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

Difference between Data staging and Dimension Table ?

Difference between Data staging and Dimension Table ?

Data Staging:
Data extraction and transformation is done here.
Meaning that, if we have source data in flat file, we extract it and load into staging tables, we take care of nulls, we change datetime format etc.. and after such cleansing/transformation at then end, load it to Dim/Fact tables
Pros: Makes process simpler and easy and also we can keep track of data as we have data in staging
Cons: Staging tables need space hence need memory space
Dimension Table:
tables which describes/stores the attribute about specific objects
Below is star schema which has dimension storing information related to Product, Customer etc..
-Vaibhav Chaudhari

How to know the timestamp of the data in a BI dimension table?

We have some BI dimension tables that we want to know the entry date of each record.
Could you please tell us how to do it?
Thanks a lot!

Hi Jessica,
Is it related to dms? if yes, then please check the field status log where you will get all the information of time and date for DIR's.
which you can use in BI reports.
I hope this will resolve the query.
Regards,
Ravindra

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

Query data being picked from which data targets and dimension tables.

Hi Guys,
I need help from you people.
My query is "If we execute any query, i want to know from which data targets and from which dimension tables data being read in the run time", is there any program or any table to find this data.
thanks in advacne.
Regards
Prasad

Hi Prasad,
We will get Data target information in query level in information TAB.
If you want get dimension tables information also you need use technical business content(bwstatistics) Cubes and need to customize the required information. I think standard statisics cubes is not provide dimention tables information. Need to customize that.
Hope it will help for you.
Thanks,
Chandra

Oracle Data Compression on SID tables and Dimension Tables

Hello Community,
We have had great success with Oracle compression on ODS tables that are no longer loaded.
We'd now like to move on to other types of BW tables that are very large.
OSS Note 701235 provides answers to questions concerning the possible use of Oracle compression together with SAP BW.
But the Note does not give suggestions for (or against) Oracle compression on SID tables or Dimension tables.
I believe both table types would exhibit the same behaviour : mostly inserts of new SID IDs and new DIM IDs, but few updates to existing SID or Dimension records. If this is true, then both are good candidates for oracle compression.
Do you also agree that this is the typical behaviour for SID tables and dimension tables ? And that these types of tables are good candidates for Oracle compression in a large BW system ?
Thanks kindly!
Keith Helfrich

Hi all,
Although this is an old thread I stumbled on during my own investigations I can provide some answers to your questions.
Table candidates for compression are found by these criteria
       - Table size big enough?
       - Long lifetime of object planned ?
      - No or only rare structural changes for the table   ?
      - u201EUpdateu201C rate low : is your data mostly kind of u201Cread onlyu201D ?
--               for the wideley used rolling window partition techniques of
                  tables in BW this is not a problem: mostly INSERTu2019s in the
                 current partition not affecting other partitions
BW tables that can benefit from compression (see SAP notes 105047,701235)
       - PSA tables with data that must be saved for a longer time
       - ODS change log (no Updates of old data, only Inserts of new data)
       - u201Ehistoricalu201C cubes wich get no changes in table structure anymore
Limitations
         - normal Insert or Update statements are stored ALWAYS in uncompressed
                format and must be compressed separately ( <= Oracle10g )
         - Slight CPU overhead of compression, butu2026
         --      CPU consumption is more than compensated by doing less I/O as
               for Bulk loads or parallel processing
         --      SAP BW transformations took a significant amount of CPU for
                   overall load-time into cubes caused by the application server not
                   the database
          - Table must have not more than 255 fields
          - Adding columns with an initial value or dropping columns require
               uncompression of the complete table (strongest limitation)
Consider all this above and you can decide that tables that going through UPDATE's are
not good candidates for compression or tables that can change it's structure (like
Fact- or DIM tables) .
Now, my questions to you:
Wich Oracle version do you use?
Wich tool do you use for Oracle compression?
BRspace (can you give an example ?)
ALTER ... MOVE COMPRESS
bye
yk

Create time dimension table in repository without data warehouse

Hi,
I want to implement only BI repository solution in my customer (not datawarehousing). Is it possible to transform the data by repository tools, so that the times columns in fact tables are categorized by the "time dimension" table?
To be more explanatory:
The "Sales" table has the "time of sale" column. It contains the timestamp when the sale was performed. I have imported this table in "physical layer" of the repository. Now I want to create a new "time dimension" table, something like:
CREATE TABLE dimension_time (
Day_Key INT NOT NULL PRIMARY KEY,
Day_Timestamp DATETIME NOT NULL,
Day_Name NVARCHAR(32) NOT NULL,
Day_Text NVARCHAR(32) NOT NULL,
INSERT INTO dimension_time VALUES (20110101, {d '2011-01-01'}, '1/1', 'January 1', 'Saturday', 0, 6, 1, 1, 185, 1, 201052, 'W52', 'Week 52', 52, 201101, '01', 'January', 1, 7, 1004, 'Winter', 'Winter', 20111, 'Q1', '1st Quarter', 1, 20103, 'Q3', '3rd Quarter', 3, 20111, 'S1', '1st Semester', 1, 20102, 'S2', '2nd Semester', 2, 2011, '2011', '2011', 2010, '10/11', '2010/2011', 0);
INSERT INTO dimension_time VALUES (20110102, {d '2011-01-02'}, '2/1', 'January 2', 'Sunday', 0, 7, 2, 2, 186, 2, 201052, 'W52', 'Week 52', 52, 201101, '01', 'January', 1, 7, 1004, 'Winter', 'Winter', 20111, 'Q1', '1st Quarter', 1, 20103, 'Q3', '3rd Quarter', 3, 20111, 'S1', '1st Semester', 1, 20102, 'S2', '2nd Semester', 2, 2011, '2011', '2011', 2010, '10/11', '2010/2011', 0);
and after to add a new column in "sales" fact table for "time dimension ID" and through the repository populate this column based on the "time of sale" column and the corresponding "time dimension ID".
I know that the ETL process might perform it, but I do not want to go for Data Warehousing (it is not real - time, needs more resources, etc).
Is it possible to perform such action only on repository?
Thank you.

Hi,
I can do it, but this would be usefull only to create "time dimension" table. But also the "sales" fact table needs to be altered (thus, the "time" column will not contain the value of the time, but the ID of the corresponding time in the "time dimension" table).
I know that on DW this procedure is done automatically by the ETL process.
My question is that does the repository has any tools similar to this?
Thank you.

Dimension table design Data modeling question

Hi Experts,
Sorry if I am putting my question in a wrong forum and please suggest an appropriate forum.
need your opinion on the existing design of our 10 years old datawarehouse.
There is one dimension table with structure like following
Dimension Table
Dimension Key Number (THIS IS NOT A PRIMARY KEY)
Natural key (from source) Number
source name character
current record indicator char(1)
form_date date
to_date date
many other columns, which if change a new current record is created and previous is marked as H-historical
Data is stored in the dimension table like this
Dimension_key Natural key Source Name current record ind from_date to_date
1 10001 Source1 H 1-jan-2005 31-may-2005
1 10001 Source1 H 1-jun-20005 12-dec-2011
1 10001 Source1 C 13-dec-2011 NULL
2 20002 Source1 H 1-jun-20001 12-dec-2011
2 20002 Source1 C 13-dec-2011 NULL
The problem I see in this design is that there is no surrogate key, if any attribute is changed the new record is inserted by first taking the dimension key based on the (natural_key,source_name,current_record_ind).
Shouldn't it be stored like following based on the data-warehousing principals.
Dimension_key Natural key Source Name current record ind from_date to_date
1 10001 Source1 H 1-jan-2005 31-may-2005
2 10001 Source1 H 1-jun-20005 12-dec-2011
3 10001 Source1 C 13-dec-2011 NULL
4 20002 Source1 H 1-jun-20001 12-dec-2011
5 20002 Source1 C 13-dec-2011 NULL
Please let me know the pros and cons of the current design.

And what if you have both the features something like this :
Lineno Dimension_key Natural key Source Name current record ind    from_date         to_date
     1              1       10001     Source1                  H   1-jan-2005     31-may-2005
     2              1       10001     Source1                  H 1-jun-20005     12-dec-2011
     3              1       10001     Source1                  C 13-dec-2011            NULLI mean just add a new column and populate it with required order by clause. Because what i guess, that in the second example you just added a new column which is something like a line number.
Regards
Girish Sharma

Creation of a Date Dimension Table

Similar Messages

Maybe you are looking for