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).
|
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:
|
Link with attached sat |
Anyways, this is just one special case out of many that heureka ModGen is capable of indentifying and generating correctly. Other cases will probably be discussed in other posts, so keep up reading!
If you are currently trying to generate a case heureka ModGen is not capable of, feel free to contact us. We will take it into account and will perhaps include them in future releases.