Minor LSAT updates

Author: RoelantVos

design-patterns/design-pattern-data-vault-hub.md

@@ -34,7 +34,7 @@ This pattern is applicable for the process of loading from the Staging Layer int
 
 ## Structure
 
-A Hub table contains the unique list of business key, and the corresponding Hub ETL process can be described as an �insert only� of the unique business keys that are not yet in the the target Hub.
+A Hub table contains the unique list of business key, and the corresponding Hub ETL process can be described as an 'insert only' of the unique business keys that are not yet in the the target Hub.
 
 The process performs a distinct selection on the business key attribute(s) in the Staging Area table and performs a key lookup to verify if the available business keys already exists in the target Hub table. If the business key already exists the row can be discarded, if not it can be inserted.
 

design-patterns/design-pattern-data-vault-link-satellite-driving-key.md

@@ -9,31 +9,35 @@ uid: design-pattern-data-vault-link-satellite-driving-key
 
 > [!NOTE]
 > Depending on your philosophy on Data Vault implementation, Link Satellites may not be relevant or applicable.
-> This is especially applicable to the driving key mechanism.
 > There are very viable considerations to implement a Data Vault model *without* Link-Satellites.
+> This is especially applicable to the driving key mechanism.
 
 ## Purpose
 
-This design pattern describes how to represent cross-key end-dating for a Link-Satellite in Data Vault methodology. In Data Vault, Link-Satellite tables manage the change for relationships over time, but there might not be a good data-driven candidate to evaluate when certain relationships are valid.
+This design pattern describes how to represent cross-key end-dating for a Link-Satellite in Data Vault methodology.
+
+In Data Vault, Link-Satellite tables are an option that can be used manage the context (and changes for) relationships over time. In many cases, the context includes attributes that can be used to evaluate if a relationship can be considered 'active', or not, at a point in time.
+
+For example, if an attribute 'is valid' or equivalent exists, this data can be used to determine if a relationship is valid and can be used for downstream data delivery. However, depending on the systems and data that are available, there might not always be a good data-driven candidate to evaluate the validity of a relationship.
+
+The 'driving key' mechanism is a special technique to apply validity of relationships when there are no reliable data points to do so.
 
 ## Motivation
 
 To provide an approach for establishing validity for Link Satellites, when no context is available to define validity of the relationship in time.
 
 ## Applicability
 
-This pattern is only applicable for loading data to Link-Satellite tables from:
-
-* The Staging Area into the Integration Area.
-* The Integration Area into the Interpretation Area.
-* The only difference to the specified ETL template is any business logic required in the mappings towards the Interpretation Area tables.
+This pattern is applicable for processing data for a Link-Satellite table, or its keyed-instance (relationship describing Hub) equivalent.
 
 ## Structure
 
- Standard Link-Satellites use the Driving Key concept to manage the ending of �old� relationships.
+Standard Link-Satellites use the Driving Key concept to manage the ending of �old� relationships.
 
 ## Implementation Guidelines
 
+To avoid data redundancy, it is recommended to manage this process into the target table as opposed to using end-dating.
+
 ## Considerations and Consequences
 
 ## Related Patterns