In the business objects layer, we can prepare a denormalized output based on the data vault core. A business object can be composed of fields coming from multiple related elements in the data vault. The Business Object generator will take away the work of manually joining the data vault elements and generates an as-of-now-view, on top of which the business logic can be applied in the business rules.
A business object is a denormalized view layered on top of the datavault. It delivers an as-of-now-view, based on the data-set of a chosen granularity satellite.
When creating a new business object and selecting a hub, additional technical fields are available, such as effective last seen date of a record or if the record was flagged as deleted in the source.
- Search Bar
Allows to search for an existing business object and open it in the business object generator.
- Create Business Object
Opens up the dialogue for Creating a Business Object.
- Add Related Business Object
Opens up the dialogue to create a related business object. The button is only active, if a business object is currently open in the business object generator. It will invoke the dialogue to create a business object and preselect the starting hub. For details: Model a dimensional output.
- Business Object Slider
The slider will open up after creating a business object or when opening an existing business object. It lets you see and compose the output of the business object.
- Element Selector
The visual selection is available after creating a business object or when opening an existing business object. It lets you select an element from the data vault you would like to take fields from.
- Auto Matching
Switches the available columns mode into auto matching. Allows to map columns to existing output columns based on the naming. Mainly used for refactoring or aligning related business objects. Alternatively, columns can be remapped by drag & drop of a new column onto the source in the output.
Creating a Business Object¶
Navigate to the business objects module and click onto “Create business object”. Fill out the fields of the dialogue and confirm the creation. Add attributes from the datavault to your output.
- Start Hub
Declaration, based on which hub the business object should start from. Will determine the primary name of the business object.
- Source System
Declaration, for which source system the business object should be generated.
- Start Data Set
Defines the dataset, which is delivered to the output. E.g. if selecting a satellite, the output grain will be based on the records in the satellite. If selecting the hub, all keys from the hub will be used for the grain.
Custom notes about the Business Object. Appears as well in the documentation.
- Functional Suffix Name
Displayed suffix name for the business object.
- Functional Suffix ID
Technical suffix, which is appended to the created view.
- SCD Type
Defines the type of historization (based on the DWH history in the vault) to be output. In most cases SCD Type 1 is recommended. The created business object will resolve the technical historization automatically based on the type.
- Create Business Object
Button to complete the creation dialougue.
Working with the Business Object Generator¶
Once a business object is created, you can modify its output using the business object generator.
- Adding attributes to the output
Use the element selector and either click onto a hub or a satellite, to select a data vault object.
The available columns will appear in the left part of the business object slider.
Select a column you would like to have in the output.
Rename the column into a business relevant terminology.
- Available technical attributes
Certain attributes are automatically available within the environment, such as last seen timestamps in delta loads. With the help of these fields, you can for example cleanse outputed data from deleted records in the source.
Data Vault Object Type
Available for BO SCD Type
Available technical attribute
Load Time - Timestamp when the record was inserted into the Hub
Load Source - Source from which the record was inserted
Delta Load Last Seen (per Staging Table) - Timestamp for when the key has been seen a delta load the last time
Inscription Time Last Seen (per Staging Table) - Timestamp for when the key has been seen in a cdc load the last time (based on inscription time)
Full Load Validity Change (per Staging Table) - Timestamp for last state change (added/deleted) of a key in a full load
Full Load Valid (per Staging table) - If the key was part of a full load, flags if the key was in the last full load or not
Load Time Transaction Link - Timestamp when the record was inserted into the Transaction Link
Load Time Satellite - Timestamp when the record was inserted into the Satellite
Inscription Time Satellite - Inscription Timestamp when the record from the source for a cdc load
Entry is Present in Satellite - Flags if the key is available in the Satellite
Load Time Link - Timestamp when the record was inserted into the Link
Load Source Link - Source from which the record was inserted
Effective Last Seen Time Link (over all Staging Tables / Systems) - Timestamp when the record was effectively seen the last time in a full or delta load
Delta Load Last Seen Time Link (over all Staging Tables / Systems) - Timestamp, when the record was seen the last time in a delta load
Full Load Last Validity Change Time Link (over all Staging Tables / Systems) - Timestamp for the last state change (added/deleted) of a record in the link
For the SCD Type 2 Object, in the output automatically the following three fields are added which are used to resolve the historical view of the data:
<businessobject_view_id>_lt: Load time start of the time slice
<businessobject_view_id>_lt_end: Load time end of the time slice
<businessobject_view_id>_bklt: Combined business key with load time to have an identifier for the time slice
You can follow along related objects in the element selector as it is possible in the data vault module, too, by double-clicking onto a hub. Some elements can appear in a gray color. In this case, it is not possible to select columns yet, as no data vault load has been defined yet to follow along the relation. Please first add a load for the link.
An important difference to the representation in the data vault is, that hubs, connected by more than one link, will be represented as two separate hubs. This way you can directly indicate, which relation to follow for the joins.
- Traversing Links / available related objects
While modelling in the Datavault, the expected cardinality of a link was already defined. Based on this information, the business object generator can support you in following relations / traversing links and prevent basic errors leading to a fanning in the output data. This means, you can only follow along many-to-1, 1-to-1 and many-to-many (explicitly expected fanning) links, but not 1-to-many.
Deleting a Business Object¶
A business object can only be deleted, if no customized business rules are declared anymore. Therefore, previously remove all business rules. An exception to this is the unaltered default ruleset, which will automatically be removed when deleting the business object. If the unaltered business ruleset is still fed into the accesslayer, the deletion will automatically remove it from the accesslayer as well.
If a dependent business ruleset exists, the deletion will directly return an error message.
Using Point In Time Tables (PIT)¶
A PIT is used to simplify historical queries against the Datavault. It combines the different time slices of the involved objects (satellites, hubs, …) and prepares an SCD type 2 output. To improve query performance, this output is materialized on the database and then used to simplify the joins in the related business objects.
PITs are created implicitly when creating a business object of scd type 2. In this process, the relevant fields of used objects are automatically added into the PIT table (meaning that only used fields will also be added to the PIT to optimize the amount of processed data).
Once you have created a PIT, it will appear in the Lineage from where it can be loaded. Additionally, it will be included into the jobs having loads for objects delivering data to the PIT. A PIT can therefore be present in jobs of multiple systems. It will automatically be loaded once none of the source objects (Hubs / Links / Satellites) is loading anymore.
The fields used in PITs are not removed automatically. If a PIT is still used in the output (e.g. in a Business Object), Datavault Builder will prevent you from dropping the related Object (e.g. Satellite). In case you would like to remove unused columns, you need to remove these directly on the database. If the PIT is not used in an output anymore, it is possible to drop related objects, however, its loaded data and columns are kept as is. The PIT & its data will be dropped when the related hub object is removed.
Since PITs are only created but not loaded while modelling, the business object output first might be empty. When pulling in new fields, make sure to reload the PIT(s) to see data in the output.
When deleting related objects data (link, satellite), the content of the pit remains untouched.
The content of the PIT can be reloaded from the Datavault. In case you would like to make a complete refresh, simply truncate the pit before the next load.
Having at least one of the two start / end in the businessobject output is mandatory. In case you haved removed one, you can re-add it by clicking onto the main hub of the business object.
Only one integrated PIT will be created for each hub (and its alias hubs).
BO Time start and end can not be removed from the output.
PITs (and their columns) are not automatically removed if they are not used anymore.
Many to many links can not be traversed in historized business objects.
PIT can only be loaded if the involved links have a link load or were loaded in the past.
An business object with same functional suffix id can either be created as SCD2 or SCD1 exclusively.