Data model of Universe database
Moderators: chulett, rschirm, roy
Data model of Universe database
Is there such thing as a data model of the DataStage Universe database? I am especially interested in the tables containing job logs, but would prefer a complete model. Is there one out there? Even DDL would help.
Nope, sorry. Pretty much the IP of Ascential and not made available to the general public.
Now, some folks here with years under their belts have 'hacked' into it and exposed parts. You'll see various routines posted here that take advantage of that knowledge. But in general, the answer still is no.
Word on the street is the next big release will totally change everything anyway.
Now, some folks here with years under their belts have 'hacked' into it and exposed parts. You'll see various routines posted here that take advantage of that knowledge. But in general, the answer still is no.
Word on the street is the next big release will totally change everything anyway.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
That said, it's an unconventional database in a number of ways. The main one that will thwart your desires is that there are different record structures withnin the same table. For example, the Sequential File stage record in DS_STAGETYPES has substantially more columns than the Red Brick stage.
Further, a nested-relational model is used so that, for example, a table definition record can contain a collection of column definitions each of which is a collection of column properties.
And when some of these properties can end up being parameterized, it really starts to get messy!
There are some tables that contain design-time objects. Each of these has a name beginning with DS_, for example DS_ROUTINES, DS_TRANSFORMS and so on.
There are some tables that contain run-time information. Each of these has a name beginning with RT_, for example RT_CONFIG, RT_STATUS, RT_LOG and so on.
But the underlying structure of these can only be determined by inspection, which you will find is prohibited in your license agreement (where they call it reverse engineering).
Further, a nested-relational model is used so that, for example, a table definition record can contain a collection of column definitions each of which is a collection of column properties.
And when some of these properties can end up being parameterized, it really starts to get messy!
There are some tables that contain design-time objects. Each of these has a name beginning with DS_, for example DS_ROUTINES, DS_TRANSFORMS and so on.
There are some tables that contain run-time information. Each of these has a name beginning with RT_, for example RT_CONFIG, RT_STATUS, RT_LOG and so on.
But the underlying structure of these can only be determined by inspection, which you will find is prohibited in your license agreement (where they call it reverse engineering).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.