Tidying-up continues

Author: RoelantVos

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

@@ -67,7 +67,7 @@ Multiple passes on the same Staging Layer data set are likely to be required: on
 
 Defining Hub ETL processes as atomic modules, as defined in this Design Pattern, means that many Staging Layer tables load data to the same central Hub table. All processes will be very similar with the only difference being the mapping between the Staging Layer business key attribute and the target Hub business key counterpart.
 
-## Related Patterns
+## Related patterns
 
 - [Design Pattern - Logical - Core Business Concept](xref:design-pattern-logical-core-business-concept)
 - Design Pattern 006 - Generic - Using Start, Process and End Dates

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

@@ -40,7 +40,7 @@ To avoid data redundancy, it is recommended to manage this process into the targ
 
 ## Considerations and consequences
 
-## Related Patterns
+## Related patterns
 
 * Design Pattern - Using Start, Process and End Dates
 * Design Pattern - Satellite

docs/design-patterns/design-pattern-data-vault-link-satellite.md

@@ -35,7 +35,7 @@ This pattern is only applicable for loading data to Link-Satellite tables from:
 
 ## Considerations and consequences
 
-## Related Patterns
+## Related patterns
 
 * Design Pattern - Using Start, Process and End Dates
 * Design Pattern - Satellite

docs/design-patterns/design-pattern-data-vault-link.md

@@ -62,7 +62,7 @@ Multiple passes on source data is likely to be required. In extreme cases a sing
 
 This type of ETL process is to be used for loading all link tables in both the Integration Area as well as the Interpretation Area. This is because the Link table is also used to relate raw (Integration Area) data and cleansed (Interpretation Area) data together.
 
-## Related Patterns
+## Related patterns
 
 * Design Pattern - Generic - Using Start, Process and End Dates
 * [Design Pattern - Data Vault - Hub tables](xref:design-pattern-data-vault-hub)

docs/design-patterns/design-pattern-data-vault-missing-keys-and-placeholders.md

@@ -1,5 +1,12 @@
+---
+uid: design-pattern-data-vault-missing-keys-and-placeholders
+---
+
 # Design Pattern - Data Vault - Missing Keys and Placeholders
 
+> [!WARNING]
+> This design pattern requires a major update to refresh the content.
+
 ## Purpose
 
 This Design Pattern documents how to handle situations where there are mismatches with the source business keys leading to values not being available in some cases. Due to the strict approach towards key lookups this would lead to errors in ETL. This is where placeholders are applied. The pattern assumes that source files are always first processed against Hub tables including loading any transactional tables against the Hubs.
@@ -43,5 +50,5 @@ Implementing a full taxonomy of potential unknown values as hard business rules
 Known uses
 This type of ETL process is to be used in all Hub or Surrogate Key tables in the Integration Area. The Interpretation Area Hub tables, if used, have similar characteristics but the ETL process contains business logic.
 
-## Related Patterns
+## Related patterns
 Design Pattern 008  Data Vault  Loading Hub tables.

docs/design-patterns/design-pattern-data-vault-satellite.md

@@ -57,7 +57,7 @@ Use hash values to detect changes, instead of comparing attributes separately. T
 
 Multiple passes on source data are likely to be required.
 
-## Related Patterns
+## Related patterns
 
 Design Pattern 006 - Generic - Using Start, Process and End Dates
 Design Pattern 009 - Data Vault - Loading Satellite tables

docs/design-patterns/design-pattern-dimensional-loading-from-the-persistent-staging-area.md

@@ -140,7 +140,7 @@ LEFT JOIN Table1 ON NOT (Table1.EFFECTIVE_DATETIME >= R.EXPIRY_DATETIME OR Table
 LEFT JOIN Table2 ON NOT (Table2.EFFECTIVE_DATETIME >= R.EXPIRY_DATETIME OR Table2.EXPIRY_DATETIME <= R.EFFECTIVE_DATETIME)
 ```
 
-## Related Patterns
+## Related patterns
 
 * Design Pattern 019 - Data Vault - Creating Dimensions from Hub tables.
 * Design Pattern 006 - Generic - Managing temporality by using Start, Process and End dates.

docs/design-patterns/design-pattern-dimensional-time-dimension.md

@@ -24,5 +24,5 @@ The decision not to copy the data types from the file definitions but to check a
 Known uses
 None.
 
-## Related Patterns
+## Related patterns
 Design Pattern 015 � Generic � Loading Staging Area tables.

docs/design-patterns/design-pattern-generic-control-framework.md

@@ -1,4 +1,11 @@
-# Design Pattern - Staging Layer - Staging Area Guidelines
+---
+uid: design-pattern-generic-control-framework
+---
+
+# Design Pattern - Generic - Control Framework
+
+> [!WARNING]
+> This design pattern is a placeholder awaiting content
 
 ## Purpose
 
@@ -8,12 +15,12 @@ This Design Pattern describes the reasoning for, and functionality provided by,
 
 ## Applicability
 
-This pattern is only applicable for every process in the data solution.
+This pattern is only applicable for _every_ process in the data solution.
 
 ## Structure
 
 ## Implementation guidelines
 
 ## Considerations and consequences
 
-## Related Patterns
+## Related patterns

docs/design-patterns/design-pattern-generic-data extraction from internal systems.md

@@ -1,26 +1,27 @@
 # Design Pattern - Generic - Data extraction from internal systems
 
+> [!WARNING]
+> This design pattern is a placeholder awaiting content
+
 ## Purpose
+
 This Design Pattern describes the overarching concepts related to extracting data from internal systems.
 
 ## Motivation
-- 
 
 ## Applicability
 
-
 ## Structure
-* Data must be extracted from the sources that created the data (as opposed to using copied data as a source). This is a broader Data Governance principle
-* Impacts on operational systems must be assessed and documented as part of the interface specification
-* Source system extract processes should not include the Data Warehouse transformation, aggregation and consolidation rules, this is applied later (separation of concerns)
-* Source system extracts should include control data to enable audit and reconciliation, e.g. record count, hash totals, etc. This is by default supported by the ETL process control model
-* The standard data integration tool must be used to extract data from the source systems, unless another efficient data extract utility is provided as part of the application package (this may include using SQL for ETL)
-* Implement incremental extracts where possible, as this is more scalable.
 
-## Implementation guidelines
+- Data must be extracted from the sources that created the data (as opposed to using copied data as a source). This is a broader Data Governance principle
+- Impacts on operational systems must be assessed and documented as part of the interface specification
+- Source system extract processes should not include the Data Warehouse transformation, aggregation and consolidation rules, this is applied later (separation of concerns)
+- Source system extracts should include control data to enable audit and reconciliation, e.g. record count, hash totals, etc. This is by default supported by the ETL process control model
+- The standard data integration tool must be used to extract data from the source systems, unless another efficient data extract utility is provided as part of the application package (this may include using SQL for ETL)
+- Implement incremental extracts where possible, as this is more scalable.
 
+## Implementation guidelines
 
 ## Considerations and consequences
 
-
-## Related Patterns
+## Related patterns