Registry Tables
Registry tables are an optional feature of SuperCHANNEL that you can use to simplify the process of designing target SuperSTAR databases.
By creating registry tables in your source database, you can give SuperCHANNEL additional information about your source data. The more information you put into registry tables, the less work you need to perform designing the target database in the SuperCHANNEL GUI.
For example, you can use them to tell SuperCHANNEL which source tables are the fact tables, which are the classifications, and how the classifications relate to the fact table columns. SuperCHANNEL can then use this information when it creates your output SXV4 database, without you having to manually define the relationships in the SuperCHANNEL GUI.
Registry tables are particularly useful in a scripted database building environment. If you are writing code to perform some of your ETL (Extract-Transform-Load) work, then you can have your program also create and populate the registry tables (defining the table joins and other rules). That way, your entire database build process, from source data to SXV4, can be automated under program control, without needing to manually define the star schema in the SuperCHANNEL GUI.
What Information Do Registry Tables Include?
You can use registry tables to tell SuperCHANNEL:
- Which tables are fact tables and which are classification tables.
- Which columns in classification tables contain the code and the name.
- Which fact table columns are measures.
- The labels (display names) for tables and columns.
- Which measure or count to use as the default summation.
- How to group fields when displaying the field list in the SuperSTAR clients.
- What cleansing actions to use during the build.
For example:
Without registry tables:
With registry tables:
Registry tables are particularly useful in situations where the jdbc:odbc bridge is the only way to connect to source data, as this driver does not recognise key relationships/constraints in source data.
Available Registry Tables
The following is a list of all the SuperSTAR registry tables. Click the links to learn more about each one.
Registry Table | Description |
---|---|
Root registry table (this is the main control table). If you are using registry tables, then this table is required. All the other tables are optional, but any table you want to use must be referenced by the root table. | |
An optional table that lists any database columns where you want to use the "bin" cleansing action (and the value to bin to). | |
Specifies which tables are classification tables. | |
Contains labels for columns. | |
Indicates which measure or fact table to use for the default summation. | |
Contains a label for the database. | |
Specifies which tables are fact tables. | |
Describes how to group fields when displaying the field list in the SuperSTAR clients. | |
Specifies which fact table columns are measures. | |
Specifies which tables are multi-response tables. | |
Contains labels for tables in the database. |
The order of the columns in the registry tables is important. They must be in the exact documented order.
Any column names or table names in registry tables must use the original values from the source database, not the display names or labels. You can find the correct value to use either by looking at the column names in the source database, or by connecting to the database in SuperCHANNEL and checking the Source Attributes.
For example, to specify the column highlighted below, you would use Acc_Profit, not Account Profit:
For help creating the registry tables in your source database, see the Sample Downloads page, where you can download SQL source and TDD definitions to set up your registry tables.
Registry Tables and Project Files
The information in the registry tables will be read by SuperCHANNEL when you first connect to a database. However, if you save your work as a SuperCHANNEL project, and then subsequently reload the project file, the settings in the project file will take precedence over the information in the registry tables.
For example, table labels will be read from the TABLE_LABEL registry table the first time you connect to the database, but if you subsequently connect to your database by loading a project file, SuperCHANNEL will read the labels from the project file, not the TABLE_LABEL table. This means that if you make changes to the labels in the registry table, these changes will not be picked up by SuperCHANNEL unless you reconnect to the database without using your project file.