Dienstag, 24. Juli 2018

If you have already been in touch with heureka ModGen, you will probably know the basics quite well, so the default cases (like for example which way a hub is being generated out of your staging model) shouldn’t be a problem for you to understand and implement.
But what about situations that force us to differ from such default cases? Today's blog entry will address a special use case for you to better understand the way heureka ModGen is working with it.
Let’s assume for example you have a resolution table (meaning a table for dissolving n:m relations).

Translating this into data vault, BankAccountOwner would be a link that links the two hubs Customer and BankAccount to one another. A special case here would be, if the link that is being created out of BankAccountOwner would have a sat for itself.

heureka ModGen recognizes such constructs in the following way: When preparing the source model for ModGen, each column is being provided with a data vault type (as I have already illustrated a few times). In most cases. The identification of these data vault types is not that difficult: primary keys are often being identified as BusinessKeys (BKEY), foreign keys as ForeignKeys (FKEY), and the rest will either be a descriptive field (CONT) or an object, that simlply will be ignored in the generation process (like for example meta columns).

In the above mentioned case we have two foreign keys (that together result in the primary key) and a column „Insert Date“, that contains descriptive information.
The identified column would therefore look like this:

As you can see, the table does not contain a BKEY and would therefore not create any hub. For this reason this is one of those cases where ModGen would create a link with a sat and the result would then look like this: