current and history data

[Former Member]

Hi all

Currently i'm working on a universe on terdata(3NF) in which most of the tables are type2. My requirement says they need two classes exact replica of one another one pointing to current data and other to history.

How can i achieve this? since both the classes are talking to the same tables i think i need two universes. Can i create a copy of the universe and link one to another?

1)I was thinking of applying row level security for current record indicator 1 for current data/ self joins on the tables.

2) for history they need to be able to select a date between record start and end date.

any help would be highly appreciated.

hk

[MariannevL]

Why two classes?

Do they want reports reporting on two versions at the same time?

If it is a matter of choice per report, I would use self-joins on the tables with an optional prompt for a keydate.

If no date is given (it is optional) default it to the system date (=current version).

That way both versions are possible in one universe with just one class...

I would give you the syntax, but unfortunately I do not speak teradata SQL.

But I'm sure you"ll figure it out

Hope this helps,

Marianne

[Former Member]

Do you have a history flag? How do you know what is history versus current?

If there is a flag and the data is in the same table, you can use case statements.

Create your first class with the objects such as:

Sum(CASE WHEN table.history_flag = 1 THEN table.value else 0 END)

Then duplicate the class and set the flag values to be 0.

Obviously that will depend on the columns in your table but user restrictions and separate universes are both the wrong approaches.

[Former Member]

Hi,

Applying row level security would be the better approach.

You could create three goups,

1.Only history records

2.Only current records

3.Admin/Both records.

I think by applying row level security it would be easiar for you to manage.

Now its up to you to decide how easy/tought is to apply the row level security in your universe.

Thanks,

Ravichandra K