This form is used to add, change and delete table definitions from your data warehouse metadata.
The picture, above, shows a Load table, but the same form is also used for editing Stage, Dimension and Fact tables.
The Action button at the bottom right of the screen will change label – Add, Change or Delete – depending on the reason for which this form was accessed.
The fields displayed on this form may vary, depending on the type of table being edited. Refer to the following field comments for more details.
Read-only description of the data source from which this table will be loaded.
This field will only be displayed for LOAD tables, as all other tables are sourced from the data warehouse.
Read-only description of the table which is the primary source for the table being edited.
For Load tables, this is the name of the table in the data source.
For staging, fact and dimension tables this is the name of the primary source in the data warehouse.
Note that in addition to the primary source, union and join transformations may reference additional tables.
Name by which this table will be known in the data warehouse.
Ajilius will automatically suggest a name based on the source table name, and its role in the data warehouse. You may edit that name if you wish.
Table names must be:
When loading data, note that Ajilius will automatically transform source table names into this format. For example, “Employee” is translated to “load_employee”, while “InvoiceLine” might be translated to “load_invoice_line”.
This format is globally portable across all our supported platforms.
Free-format description of the table that will be used in documentation, and passed to BI tools as the user-facing name of the table.
Must be non-blank.
If checked, this table will have its contents truncated before new data is added.
Most load tables will be automatically truncated (have previous contents deleted) each time they are loaded.
An exception to this rule might apply if you wanted to load several tables of an identical format, and concatenate them into a single table at load time.
For staging, you are unlikely to want to truncate persistent staging tables, as the idea of persistence is to keep a history of data over time.
|DQ Reject Limit||
Data Quality Rules are discussed here.
This field declares the number of rows that are allowed to fail validation before the load is terminated in error.
Most data warehouses, certainly during the development phase, will set this value to zero. This means that any error will cause the load to fail.
In production, for high volume tables, a number of rejects may be considered acceptable.
This field will only be displayed for LOAD tables, as data quality screens are applied at the point data is loaded into the warehouse.
|User & Technical Documentation||
Free-form documentation about the business purpose of this table, and any technical notes about its processing.
This information will be used to create the Ajilius documentation, and may be surfaced in BI popups, help text, etc. where supported.