Adding warnings on old content.

Author: RoelantVos

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

@@ -1,8 +1,8 @@
 ---
-uid: design-pattern-data-vault-hub-table
+uid: design-pattern-data-vault-hub
 ---
 
-# Design Pattern - Data Vault - Hub table
+# Design Pattern - Data Vault - Hub
 
 > [!WARNING]
 > This design pattern requires a major update to refresh the content.

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

@@ -1,7 +1,19 @@
-# Design Pattern - Data Vault - Loading Link Satellite tables
+---
+uid: design-pattern-data-vault-link-satellite
+---
+
+# Design Pattern - Data Vault - Link Satellite
+
+> [!WARNING]
+> This design pattern requires a major update to refresh the content.
+
+> [!NOTE]
+> Depending on your philosophy on Data Vault implementation, Link Satellites may not be relevant or applicable.
+> There are very viable considerations to implement a Data Vault model *without* Link-Satellites.
 
 ## Purpose
-This Design Pattern describes how to load data into Link-Satellite tables within a ‘Data Vault’ EDW architecture. In Data Vault, Link-Satellite tables manage the change for relationships over time.
+
+This design pattern describes how to load process data for a Data Vault methodology Link-Satellite. In Data Vault, Link-Satellite tables manage the change for relationships over time.
 
 ## Motivation
 
@@ -16,43 +28,15 @@ This pattern is only applicable for loading data to Link-Satellite tables from:
 * The only difference to the specified ETL template is any business logic required in the mappings towards the Interpretation Area tables.
 
 ## 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
-Multiple passes of the same source table or file are usually required. The first pass will insert new keys in the Hub table; the other passes are needed to populate the Satellite and Link tables.
-Select all records for the Link Satellite which have more than one open effective date / current record indicator but are not the most recent (because that record does not need to be closed
-WITH MyCTE (<Link SK>, <Driving Key SK>, <Effective Date/Time>, <Expiry Date/Time>, RowVersion)
-AS (
-  SELECT
-     A.<Link SK>, B.<Driving Key SK>, A.<Effective Date/Time>, A.<Expiry Date/Time>,
-     DENSE_RANK() OVER(PARTITION BY B.<Driving Key SK> ORDER BY B.<Link SK>, <Effective Date/Time> ASC) RowVersion
-  FROM <Link Sat table> A
-  JOIN <Link table> B ON A.<Link SK>=B.<Link SK>
-  JOIN (
-    SELECT <Driving Key SK>
-    FROM <Link Sat table> A
-    JOIN <Link table> B ON A.<Link SK>=B.<Link SK>
-    WHERE A.<Expiry Date/Time> = '99991231'
-    GROUP BY <Driving Key SK>
-    HAVING COUNT(*) > 1
-  ) C ON B.<Driving Key SK> = C.<Driving Key SK>
-)
-SELECT
-  BASE.<Link SK>
-  ,CASE WHEN LAG.<Effective Date/Time> IS NULL THEN '19000101' ELSE BASE.<Effective Date/Time> END AS <Effective Date/Time>
-  ,CASE WHEN LEAD.<Effective Date/Time> IS NULL THEN '99991231' ELSE LEAD.<Effective Date/Time> END AS <Expiry Date/Time>
-  ,CASE WHEN LEAD.<Effective Date/Time> IS NULL THEN 'Y' ELSE 'N' END AS <Current Row Indicator>
-FROM MyCTE BASE
-LEFT JOIN MyCTE LEAD ON BASE.<Driving Key SK> = LEAD.<Driving Key SK>
-  AND BASE.RowVersion = LEAD.RowVersion-1
-LEFT JOIN MyCTE LAG ON BASE.<Driving Key SK> = LAG.<Driving Key SK>
-  AND BASE.RowVersion = LAG.RowVersion+1
-WHERE BASE.<Expiry Date/Time> = '99991231'
 
 ## Considerations and Consequences
-Multiple passes on source data are likely to be required.
 
 ## Related Patterns
-* Design Pattern 006 – Using Start, Process and End Dates
-* Design Pattern 009 – Loading Satellite tables.
-* Design Pattern 010 – Loading Link tables.
+
+* Design Pattern - Using Start, Process and End Dates
+* Design Pattern - Satellite
+* Design Pattern - Link

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

@@ -1,15 +1,11 @@
 ---
-uid: design-pattern-data-vault-link-table
+uid: design-pattern-data-vault-link
 ---
 
-# Design Pattern - Data Vault - Loading Link tables
+# Design Pattern - Data Vault - Link
 
----
-**NOTE**
-
-This design pattern requires a major update to refresh the content.
-
----
+> [!WARNING]
+> This design pattern requires a major update to refresh the content.
 
 ## Purpose
 

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

@@ -1,9 +1,11 @@
 # Design Pattern - Data Vault - Missing Keys and Placeholders
 
 ## 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.
 
 ## Motivation
+
 This pattern focuses on processing data from dodgy sources that actually contain NULL business keys.  When a business key is NULL this should be resolved to a placeholder (dummy Surrogate Key).
 The reasoning behind this is to prevent overcomplicated error handling while loading data into the (raw) Data Vault; supporting the goal to load everything just as the source system provides it while at the same time preventing losing any records.
 Also known as
@@ -12,25 +14,27 @@ Early or late arriving data.
 Empty business keys.
 
 ## Applicability
+
 This pattern is only applicable for loading data into the Integration Area tables.
 
 ## Structure
-The Enterprise Data Warehouse architecture specifies that ‘hard’ business rules are implemented on the way into the Data Warehouse (the process from the Staging Area into the Integration Area) whereas ‘soft’ business rules are implemented from the Integration Layer to the Interpretation Area and/or the Presentation Layer (on the way out).
-Using placeholders is a ‘hard’ business rule because no-one can interpret the meaning of a NULL value. SQL cannot deal with NULL values very well and because of this allowing NULL values increases the complexity of the queries against the Integration Area (potentially using outer joins). This is the reason why NULL values are remapped on the way into the Integration Area and ultimately why this kind of (hard) business logic is allowed here.
+
+The Enterprise Data Warehouse architecture specifies that �hard� business rules are implemented on the way into the Data Warehouse (the process from the Staging Area into the Integration Area) whereas �soft� business rules are implemented from the Integration Layer to the Interpretation Area and/or the Presentation Layer (on the way out).
+Using placeholders is a �hard� business rule because no-one can interpret the meaning of a NULL value. SQL cannot deal with NULL values very well and because of this allowing NULL values increases the complexity of the queries against the Integration Area (potentially using outer joins). This is the reason why NULL values are remapped on the way into the Integration Area and ultimately why this kind of (hard) business logic is allowed here.
 
 For example, here are some reasons how NULL values can be presented instead of business keys:
-The source declares them as optional Foreign Keys; for instance when ‘X’ is true, then the business key is populated. Otherwise the business key remains NULL.
+The source declares them as optional Foreign Keys; for instance when �X� is true, then the business key is populated. Otherwise the business key remains NULL.
 The source declares them as required but the declaration is broken or not enforced (there is an error in the source application that allows NULLS when it shouldn't).
 Implementation guidelines
-NULL/unknown/undefined business key values can be mapped to various placeholder surrogate key values (-1 to -7 surrogate key values) with descriptions like ‘Not Applicable’, ‘Unknown’ or anything that fits the business key domain. The taxonomy usable for most situations is (not all values are applicable in all situations):
-Missing (-1): the root node and supertype of all ‘missing’ information, it encompasses:
-Missing value (-2): supertype of all missing values. Can be ‘Unknown’ or ‘Not Applicable’:
+NULL/unknown/undefined business key values can be mapped to various placeholder surrogate key values (-1 to -7 surrogate key values) with descriptions like �Not Applicable�, �Unknown� or anything that fits the business key domain. The taxonomy usable for most situations is (not all values are applicable in all situations):
+Missing (-1): the root node and supertype of all �missing� information, it encompasses:
+Missing value (-2): supertype of all missing values. Can be �Unknown� or �Not Applicable�:
 Not Applicable (-3).
 Unknown (-4).
 Missing Attribute/Column (-5): supertype of all missing values due to missing attributes:
 Missing Source Attribute (Non recordable Source) (-6). Used when source fails to supply attribute/column
 Missing Target Attribute (Non recordable DWH Attribute) (-7). Used for temporal data that falls before the deployment of the attribute.
-Deciding between the various types of ‘unknown’ is a business question that is decided based on how the source database works.
+Deciding between the various types of �unknown� is a business question that is decided based on how the source database works.
 
 ## Considerations and Consequences
 The Hubs must be pre-populated with the placeholder values (records).
@@ -40,4 +44,4 @@ 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
-Design Pattern 008 – Data Vault – Loading Hub tables.
+Design Pattern 008 � Data Vault � Loading Hub tables.

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

@@ -1,11 +1,11 @@
-# Design Pattern - Data Vault - Satellites table
-
 ---
-**NOTE**
+uid: design-pattern-data-vault-satellite
+---
 
-This design pattern requires a major update to refresh the content.
+# Design Pattern - Data Vault - Satellite
 
----
+> [!WARNING]
+> This design pattern requires a major update to refresh the content.
 
 ## Purpose