Tidy-ups - continued

Author: RoelantVos

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

@@ -40,7 +40,7 @@ The process performs a distinct selection on the business key attribute(s) in th
 
 During the selection the key distribution approach is implemented to make sure a dedicated Data Warehouse key is created. This can be an integer value, a hash key (i.e. MD5 or SHA1) or a natural business key.
 
-## Implementation Guidelines
+## Implementation guidelines
 
 Hubs are core business concepts which must be immediately and uniquely identifiable through their name.
 
@@ -61,7 +61,7 @@ When modeling the Hub tables try to be conservative when defining the business k
 
 To cater for a situation where multiple Load Date / Time stamp values exist for a single business key, the minimum Load Date / Time stamp should be the value passed through with the HUB record. This can be implemented in ETL logic, or passed through to the database.  When implemented at a database level, instead of using a SELECT DISTINCT, using the MIN function with a GROUP BY the business key can achieve both a distinct selection, and minimum Load Date / Time stamp in one step.
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 Multiple passes on the same Staging Layer data set are likely to be required: once for the Hub table(s) but also for any corresponding Link and Satellite tables.
 

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

@@ -34,11 +34,11 @@ This pattern is applicable for processing data for a Link-Satellite table, or it
 
 Standard Link-Satellites use the Driving Key concept to manage the ending of old relationships.
 
-## Implementation Guidelines
+## 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
+## CConsiderations and consequences
 
 ## Related Patterns
 

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

@@ -31,9 +31,9 @@ This pattern is only applicable for loading data to Link-Satellite tables from:
 
  Standard Link-Satellites use the Driving Key concept to manage the ending of old relationships.
 
-## Implementation Guidelines
+## Implementation guidelines
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 ## Related Patterns
 

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

@@ -39,7 +39,7 @@ Business Insights > Design Pattern 010 - Data Vault - Loading Link tables > imag
 
 In a pure relational Link it is required that a dummy key is available in each corresponding Link-Satellite to complete the timelines. This is handled as part of the Link-Satellite processing as a Link can contain multiple Link-Satellites. Dummy records are only required to be inserted for each driving key as a view in time across the driving key is ultimately required. Inserting a dummy record for every Link key will cause issues in the timeline. This is explained in more detail in the Link-Satellite Design Pattern.
 
-## Implementation Guidelines
+## Implementation guidelines
 
 Use a single ETL process, module or mapping to load the Link table, thus improving flexibility in processing. Every ETL process should have a distinct function.
 
@@ -56,7 +56,7 @@ The default and arguably most flexible way is to incorporate this concept as par
 Depending on how the Link table is modelled (what kind of relationship it manages) the Link table may contains a relationship type attribute. If a link table contains multiple, or changing, relationships (types) this attributes is moved to the Link-Satellite table.
 Ending /closing relationships is always done in the Link-Satellite table, typically using a separate ETL process.
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 Multiple passes on source data is likely to be required. In extreme cases a single source table might be used (branch out) to Hubs, Satellites, Links and Link Satellites.
 

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

@@ -36,7 +36,7 @@ Missing Source Attribute (Non recordable Source) (-6). Used when source fails to
 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.
 
-## Considerations and Consequences
+## CConsiderations and consequences
 The Hubs must be pre-populated with the placeholder values (records).
 ETL processes loading data into the Integration Area must automatically resolve NULL values to (potentially different) placeholders.
 Implementing a full taxonomy of potential unknown values as hard business rules must be weighed against extra complexity while loading Integration Area tables.

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

@@ -28,7 +28,7 @@ The ETL process can be described as a slowly changing dimension / history update
 Load Date / Time Stamp (used for the target Effective Date / Time and potentially the Update Date / TimeE attributes).
 Source Row Id.
 
-## Implementation Guidelines
+## 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.
 
@@ -53,7 +53,7 @@ If you have a Change Data Capture based source, the attribute comparison is not
 
 Use hash values to detect changes, instead of comparing attributes separately. The hash value is created from all attributes except the business key and ETL process control values.
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 Multiple passes on source data are likely to be required.
 

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

@@ -43,12 +43,12 @@ Therefore, the logic is slightly more complex. Joining Persistent Staging Area t
 
 ### Example Datasets
 
-| HSTG Table 1 | Key | INSERT_DATETIME | Fund Code | Amount     |
+| PSA Table 1 | Key | INSERT_DATETIME | Fund Code | Amount     |
 |--------------|-----|-----------------|-----------|------------|
 |              | 1   | 2012-01-01      | ABC       | $1,000,000 |
 |              | 2   | 2013-06-02      | ABC       | $1,500,000 |
 
-| HSTG Table 2 | Key | INSERT_DATETIME | Fund Code | Short Name | Additional Amount |
+| PSA Table 2 | Key | INSERT_DATETIME | Fund Code | Short Name | Additional Amount |
 |--------------|-----|-----------------|-----------|------------|-------------------|
 |              | 1   | 2012-04-05      | ABC       | ABC Corp   | $5,000            |
 |              | 2   | 2013-07-07      | ABC       | ABC Pty    | $5,000            |
@@ -79,9 +79,9 @@ Therefore, the logic is slightly more complex. Joining Persistent Staging Area t
 ```sql
 -- Select all variations of the available time intervals
 WITH TimeIntervals AS (
-  SELECT INSERT_DATETIME FROM HSTG_Table1
+  SELECT INSERT_DATETIME FROM PSA_Table1
   UNION
-  SELECT INSERT_DATETIME FROM HSTG_Table2
+  SELECT INSERT_DATETIME FROM PSA_Table2
 ),
 
 -- Calculate the ranges (time intervals / slices) between available time intervals
@@ -99,32 +99,32 @@ Ranges AS (
 -- Connect source table 1
 Table1 AS (
   SELECT
-    c.HSTG_Table1_SK,
+    c.PSA_Table1_SK,
     c.Fundcode,
     c.Total_Amount,
     c.INSERT_DATETIME AS EFFECTIVE_DATETIME,
     COALESCE(MIN(c2.INSERT_DATETIME), CONVERT(DATETIME, '99991231')) AS EXPIRY_DATETIME
-  FROM HSTG_Table1 c
-  LEFT JOIN HSTG_Table1 c2 ON
+  FROM PSA_Table1 c
+  LEFT JOIN PSA_Table1 c2 ON
     c.Fundcode = c2.Fundcode AND
     c.INSERT_DATETIME < c2.INSERT_DATETIME
-  GROUP BY c.HSTG_Table1_SK, c.Fundcode, c.Total_Amount, c.INSERT_DATETIME
+  GROUP BY c.PSA_Table1_SK, c.Fundcode, c.Total_Amount, c.INSERT_DATETIME
 ),
 
 -- Connect source table 2
 Table2 AS (
   SELECT
-    c.HSTG_Table2_SK,
+    c.PSA_Table2_SK,
     c.Fundcode,
     c.Short_name,
     c.Additional_amount,
     c.INSERT_DATETIME AS EFFECTIVE_DATETIME,
     COALESCE(MIN(c2.INSERT_DATETIME), CONVERT(DATETIME, '99991231')) AS EXPIRY_DATETIME
-  FROM HSTG_Table2 c
-  LEFT JOIN HSTG_Table2 c2 ON
+  FROM PSA_Table2 c
+  LEFT JOIN PSA_Table2 c2 ON
     c.Fundcode = c2.Fundcode AND
     c.INSERT_DATETIME < c2.INSERT_DATETIME
-  GROUP BY c.HSTG_Table2_SK, c.Fundcode, c.Short_Name, c.Additional_Amount, c.INSERT_DATETIME
+  GROUP BY c.PSA_Table2_SK, c.Fundcode, c.Short_Name, c.Additional_Amount, c.INSERT_DATETIME
 )
 
 -- Join tables to time ranges

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

@@ -19,10 +19,10 @@ Implementation guidelines
 Every separate source system has its own directory in the landing area.
 Every source directory has an archive directory.
 
-## Considerations and Consequences
+## CConsiderations and consequences
 The decision not to copy the data types from the file definitions but to check and explicitly convert these in the ETL process will mean that explicit checks and data type conversions will have to be added later.
 Known uses
 None.
 
 ## Related Patterns
-Design Pattern 015 – Generic – Loading Staging Area tables.
+Design Pattern 015 � Generic � Loading Staging Area tables.

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

@@ -12,8 +12,8 @@ This pattern is only applicable for every process in the data solution.
 
 ## Structure
 
-## Implementation Guidelines
+## Implementation guidelines
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 ## Related Patterns

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

@@ -17,10 +17,10 @@ This Design Pattern describes the overarching concepts related to extracting dat
 * 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
+## Implementation guidelines
 
 
-## Considerations and Consequences
+## CConsiderations and consequences
 
 
 ## Related Patterns