Point In Time And Effective Date Reporting Using Discoverer

As a trainer/ consultant one of the biggest issues and hardest concepts to get across to a classroom is the way that data is returned from a database that contains date tracked information. The biggest and most visual way this shows itself on a report is when for example an employee shows on a report with 2, 3 or more lines of information, or as it is called multiple rows. Obviously this makes the information being reported on somewhat useless, as we usually look for one entry per person, so when we start to do further analysis of the returned data, i.e. trying to sum hours worked columns or creating average calculations, we are not seeing the results inflated by multiple entries on the report. There are ways to overcome this using simple functionality in Discoverer and we will explore these later, but first we need to understand where the problem came from in the first place. To do this we will focus on three tables where information is held on the database, Person, Assignment and Position. In this example the Employees Position table only contains one entry as this has not changed during their employment. Staff Number 00112233 Position Start 01-Apr-2001 Position End 31-Dec-4712

We have a clear start date and a clear end date for the record. Next we have the Assignment table. Staff Number 00112233 00112233 00112233 Assignment Start 24-nov-2006 16-Mar-2003 01-Apr-2001 Assignment End 31-Dec-4712 23-Nov-2006 15-Mar-2003 FTE 1 0.75 0.5

As you can see from the table above the database has created a new line in the assignment table to cater for the date tracked data item in this case FTE, and we now have 3 rows which could be returned for this employee.

Now we have to consider a third table, the Person Table. Staff Number 00112233 00112233 00112233 Person Start 24-jan-2009 16-May-2005 01-Apr-2001 Person End 31-Dec-4712 23-Jan-2009 15-May-2005 Contact Address Aberdeen, George St. Croydon, Mill St. Swindon, High St.

Assuming that todays date is 01-Oct -2008 we can see we have a future date tracked change of address already inputted in this employees person record which is driving out the top line of the table. If we were to run a report now for this person without any conditions we would be seeing many rows for this employee in our report reflecting the historic and future date tracked changes being stored. To reduce the effect of multiple rows for this employee, it should be a simple case of building a condition in Discoverer to restrict the data being returned to 31-DEC-4712

Position End date= 31-DEC-4712 AND Assignment End Date= 31-DEC-4712 AND Person End Date= 31-DEC-4712

Whilst this would have the effect of reducing the information returned for the employee to one row, what would happen if we now wanted to send a letter to our employee using the data in the report? The address information being returned equal to 31-dec-4712 is incorrect (remember we are saying 01-Oct-2008 is today) and the record for this date will not become true until 24-Jan2009, the employee is currently living in Croydon and not Aberdeen.

There are 2 ways around this: 1. Use a condition to restrict to a single point in time using the function SYSDATE. 2. Build an Effective Date parameter allowing the end user to select any point in time to view that information for.

Option 1, A Simple Condition. We can write a very simple condition using the database function SYSDATE (System Datetodays date) to look for records that match the criteria.

=SYSDATE BETWEEN Position Start Date AND Position End date AND =SYSDATE BETWEEN Assignment start date AND Assignment End Date AND =SYSDATE BETWEEN Person Start date AND Person End Date

This will have the desired result; it will return one row per employee for a single point in time SYSDATE. The draw-back to this is that it will only ever return data as of SYSDATE and may not give the end user the flexibility they require to return historic or future dated information. Hence option 2.

Option 2. Creating a Report Effective Date Parameter. Normally to create a parameter in Discoverer we would build the parameter around an existing data item. Report Effective Date does not exist in the data base as a data item so we are going to build a None Data Item based parameter. This is a three stage process: 1. Create the parameter 2. Create a calculation 3. Create a condition

Creating The Parameter. The first stage is to create a parameter not using a specific data item but selecting the None option when prompted to select a data item. When you do this the Create a condition field will grey out, this is because we cannot build a condition on something that does not exist in the data base. After populating the user prompts, we will give our parameter a default value of Today.

We have created 3 problems here, firstly there is no condition at the moment, the system has greyed the field out, so we will have to create one, also we have given our parameter which is based on nothing a default value of Today and in the user prompt field instructed them they can enter any date into the system. We get over this with a calculation.

Creating The Calculation. When creating any calculation in Discoverer, the output will always be in the form of a data point, usually then used as a column in a report to give the result of the calculation. We are going to use our calculation to create a Report Effective Date data point, that we can then call into a condition as in stage 3. We are also going to use the calculation to covert a user inputted (text) date into a true date and to convert the parameter default of Today into SYSDATE, as shown below:

Lets break this down: DECODE creates an If statement (use CASE for If, Then, Else) :Report Effective Date (note the :) is our parameter. TRUNC is truncate, so TRUNC(SYSDATE) returns 01-OCT-2008 from 01-OCT-2009 13:45. TO_DATE converts a character input to a date format as specified DD-MON-YYYY

So the calculation reads If the input from the parameter is Today output SYSDATE, otherwise covert to a date the text inputted into the parameter and output that as a date. As the output for the calculation is a new data point, we would now have a new column in our report called Report Effective Date showing the result of the calculation, either SYSDATE or the date specified by the end user. Although we now have a parameter that now functions, we still have our original multiple row problem for our employee.

Creating The Condition. The final part of the process is to create a condition that uses the data item derived from the calculation (Report Effective Date) and uses this to check for matching rows on the tables being reported on. The condition would read like this: Report Effective Date BETWEEN Person Start AND Person End AND Report Effective Date BETWEEN Position Start AND Position End AND Report Effective Date BETWEEN Assignment Start AND Assignment End

Now when you run the Report Effective Date parameter it will feed your input into the calculation, the output of which will feed into the condition, which will check that against the data items stated in the condition and restrict the data accordingly. This should then give you a single row per employee in the report.