The function of a link entity seems to be very similar like an hub entity. A hub entity is a view on a business object and in the same way a link entity descibes a business relationship.2) This business relationship has to be unique, specific and traceable with business rules3). A link will always be designed as an own entity4) and contains neither business keys nor describing data. For this request hubs and satellites will be used5). To get the most flexibility links are always “M:N-relationships”. This means that entity A can be related to no, one or more objects of entity B.6) If the system has to be expanded it is very comfortable to redesign the data modell because with these “M:N-relationships” every object can be connected very simple with any other object.7) However it is not easily to see if just a 1:M- relationship exists. The usage of a (modelled) M:N-relationship as an (real) 1:M-relationship is possible without difficulty.
The following figure shows the basically principle to use a link to connect 3 hubs:8)
The link L_customer_sale in the diagram above (green) implements a M:N-relationship with using the primary keys of the hubs (marked as foreign keys (FK) in the link entity). Additional in the link a surrogate_key named L_customer_sale_SID will be inserted to uniquily identify the link.
Otherwise meta data will be designed in a link for example to identify the source system where the data comes from or the timestamp when the data exists the first time in the system. This meta data will be explained in the next chapter.
Meta data like a timestamp or a session key are always defined in a link.9) The following table shows some standart meta data with a short explanation:
|FK||foreign key to the connected entities|
|date_time_stamp||timestamp of inserting the data set|
|Record_source||source system where the data set comes from|
<nspages design:data-vault:entities:link -h1 -textPages=“” -exclude:start >