Typo

RoelantVos · RoelantVos · commit 9b08118cb257 · 2025-07-06T14:57:50.000+10:00
diff --git a/docs/design-patterns/design-pattern-data-vault-hub.md b/docs/design-patterns/design-pattern-data-vault-hub.md
@@ -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.
 
-## CConsiderations and consequences
+## Considerations 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.
 
diff --git a/docs/design-patterns/design-pattern-data-vault-link-satellite-driving-key.md b/docs/design-patterns/design-pattern-data-vault-link-satellite-driving-key.md
@@ -38,7 +38,7 @@ Standard Link-Satellites use the Driving Key concept to manage the ending of old
 
 To avoid data redundancy, it is recommended to manage this process into the target table as opposed to using end-dating.
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 ## Related Patterns
 
diff --git a/docs/design-patterns/design-pattern-data-vault-link-satellite.md b/docs/design-patterns/design-pattern-data-vault-link-satellite.md
@@ -33,7 +33,7 @@ This pattern is only applicable for loading data to Link-Satellite tables from:
 
 ## Implementation guidelines
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 ## Related Patterns
 
diff --git a/docs/design-patterns/design-pattern-data-vault-link.md b/docs/design-patterns/design-pattern-data-vault-link.md
@@ -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.
 
-## CConsiderations and consequences
+## Considerations 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.
 
diff --git a/docs/design-patterns/design-pattern-data-vault-missing-keys-and-placeholders.md b/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.
 
-## CConsiderations and consequences
+## Considerations 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.
diff --git a/docs/design-patterns/design-pattern-data-vault-satellite.md b/docs/design-patterns/design-pattern-data-vault-satellite.md
@@ -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.
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 Multiple passes on source data are likely to be required.
 
diff --git a/docs/design-patterns/design-pattern-dimensional-time-dimension.md b/docs/design-patterns/design-pattern-dimensional-time-dimension.md
@@ -19,7 +19,7 @@ Implementation guidelines
 Every separate source system has its own directory in the landing area.
 Every source directory has an archive directory.
 
-## CConsiderations and consequences
+## Considerations 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.
diff --git a/docs/design-patterns/design-pattern-generic-control-framework.md b/docs/design-patterns/design-pattern-generic-control-framework.md
@@ -14,6 +14,6 @@ This pattern is only applicable for every process in the data solution.
 
 ## Implementation guidelines
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-data extraction from internal systems.md b/docs/design-patterns/design-pattern-generic-data extraction from internal systems.md
@@ -20,7 +20,7 @@ This Design Pattern describes the overarching concepts related to extracting dat
 ## Implementation guidelines
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-data-integration-into-a-data-warehouse.md b/docs/design-patterns/design-pattern-generic-data-integration-into-a-data-warehouse.md
@@ -35,7 +35,7 @@
 ## Implementation guidelines
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-date-math.md b/docs/design-patterns/design-pattern-generic-date-math.md
@@ -150,7 +150,7 @@ Joining has to be done with < and > selections, which not every ETL tool support
 Some ETL tools or databases make the WHERE clause a bit more readable by providing a ‘greatest’ or ‘smallest’ function.
 This approach requires the timelines in all tables to be complete, ensuring referential integrity in the central Data Vault model. This means that every Hub has to have a record in the Satellite table with a start date of ‘01-01-1900’ and one which ends at ‘31-12-9999’ (can be the same record if there is no history yet). Without this dummy record to complete the timelines the query to calculate the overlaps will become very complex. SQL filters the records in the original WHERE clause before joining to the other history set. This requires the selection on the date range to be done on the JOIN clause but makes it impossible to get the EXPIRY_DATE correct in one pass. The solution with this approach is to only select the EFFECTIVE_DATE values, order these, and join this dataset back to itself to be able to compare the previous row (or the next depending on the sort) and derive the EXPIRY_DATE. In this context the solution to add dummy records to complete the timelines is an easier solution which also improves the integrity of the data in the Data Vault model.
 
-## CConsiderations and consequences
+## Considerations and consequences
 This approach requires the timelines in all tables to be complete, ensuring referential integrity in the central Data Vault model. This means that every Hub has to have a record in the Satellite table with a start date of ‘01-01-1900’ and one which ends at ‘31-12-9999’ (can be the same record if there is no history yet). Without this dummy record to complete the timelines the query to calculate the overlaps will become very complex. SQL filters the records in the original WHERE clause before joining to the other history set. This requires the selection on the date range to be done on the JOIN clause but makes it impossible to get the EXPIRY_DATE correct in one pass. The solution with this approach is to only select the EFFECTIVE_DATE values, order these, and join this dataset back to itself to be able to compare the previous row (or the next depending on the sort) and derive the EXPIRY_DATE. In this context the solution to add dummy records to complete the timelines is an easier solution which also improves the integrity of the data in the Data Vault model.
 Known uses
 
diff --git a/docs/design-patterns/design-pattern-generic-exception-handling.md b/docs/design-patterns/design-pattern-generic-exception-handling.md
@@ -680,7 +680,7 @@ Exception handling in the Presentation Layer is directly related to the function
 
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 TBD
 
diff --git a/docs/design-patterns/design-pattern-generic-exposing-data-from-the-data-warehouse.md b/docs/design-patterns/design-pattern-generic-exposing-data-from-the-data-warehouse.md
@@ -17,7 +17,7 @@
 ## Implementation guidelines
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-full-outer-join-interfaces.md b/docs/design-patterns/design-pattern-generic-full-outer-join-interfaces.md
@@ -46,7 +46,7 @@ By its nature, the Full Outer Join can only provide a single snapshot / historic
 
 ## Implementation guidelines
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 ## Related Patterns
 
diff --git a/docs/design-patterns/design-pattern-generic-handling-flat-files.md b/docs/design-patterns/design-pattern-generic-handling-flat-files.md
@@ -34,7 +34,7 @@ Messaging applications (brokers) typically contain built-in functionality for th
 * File lists may be used to select which files to load and to handle the changing filenames (date!). This also provides the opportunity to process multiple files at once
 * If files are delivered less frequently than the ETL process runs, for instance files are delivered weekly but the ETL process runs daily, a file list still needs to be created. This file list contains an empty dummy file so the process does not fail
 
-## CConsiderations and consequences
+## Considerations 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 in the Integration Layer. 
 
 Typically (and recommended) this is done as part of the Interpretation Layer ETL processes as this allows to process data that has quality issues. Dirty data will be loaded into the Integration Area where it can be handled accordingly for issues such as missing business keys.
diff --git a/docs/design-patterns/design-pattern-generic-handling-logical-deletes.md b/docs/design-patterns/design-pattern-generic-handling-logical-deletes.md
@@ -46,7 +46,7 @@ The Deleted Row Indicator (�Deleted� in this example) keeps the design strai
 * Treat the Deleted Row Indicator as any attribute that triggers a SCD2 mechanism.
 * If you have a Change Data Capture based source the attribute comparison may potentially be skipped because the CDC mechanisms inform the system whether the record in the Staging Area is new, updated or deleted.
 
-## CConsiderations and consequences
+## Considerations and consequences
 * A deleted record in the source system leads to an extra record in the Data Warehouse. With this in mind the meaning of the (Data Warehouse) effective and expiry dates should be very clear: they indicated the time interval for when a value/record was active.
 * This approach stores the last state of the record when it was deleted. This is a design decision. As an alternative the values can also be set to NULL although this may cause some problems when re-opening records. 
 
diff --git a/docs/design-patterns/design-pattern-generic-initial-load-and-reinitialization.md b/docs/design-patterns/design-pattern-generic-initial-load-and-reinitialization.md
@@ -27,7 +27,7 @@ For re-initialisation a single procedure or ETL process should be created to cop
 At least the transactional tables must be truncated prior to a full re-initialisation to avoid creating duplicates.
 For the initial load of non-CDC sources a proxy Load Date / Time Stamp must be defined.
 
-## CConsiderations and consequences
+## Considerations and consequences
 Running re-initialisations essentially discards and re-issues any Data Warehouse keys, which means that all related Cleansing Area and Presentation Layer datasets must be recalculated as well.
 Known uses
 An Initial Load has to be done at the end of the initial development stage for new information. Re-initialisations are typically part of bigger patches or troubleshooting. This also covers remodelling parts of the Integration Layer (the true Data Warehouse).
diff --git a/docs/design-patterns/design-pattern-generic-interfacing-from-an-operational-system.md b/docs/design-patterns/design-pattern-generic-interfacing-from-an-operational-system.md
@@ -31,7 +31,7 @@ The following list captures the fundamental requirements of an interface between
 * Consider scalability in terms of ability to add more data elements or tables to existing interfaces. In some cases significant effort may be required to add or modify interfaces, and this effort may be limited by increasing the scope of data in a single change. This is especially the case when dealing with third-party systems. It may be better to retrieve all the data in one go as in some cases the first contact is �free�, but subsequent efforts to add additional interfaces typically meet more resistance, suffer from politics or require additional funding. A downside to this approach is the extra effort both in terms of maintenance and development to load/ stage (and perhaps integrate) all tables. However, in some cases this trade-off is a positive one in the longer term when no extra communication to the source system owners is required.
 * An additional consideration is that information that is captured by the Data Warehouse can be archived in the Persistent Staging Area (PSA), which enables the solution to collect information early on in the development cycle (for use later on).
 
-## CConsiderations and consequences
+## Considerations and consequences
 Not applicable.
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-loading-landing-from-transactional-CDC.md b/docs/design-patterns/design-pattern-generic-loading-landing-from-transactional-CDC.md
@@ -75,7 +75,7 @@ In a CDC environment, the Staging Area delta selection process can only select a
 
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 This design decision focuses on establishing a scheduled (i.e. time-interval driven) delta selection based on CDC information.
 
diff --git a/docs/design-patterns/design-pattern-generic-loading-staging-area-tables-using-row-compacting.md b/docs/design-patterns/design-pattern-generic-loading-staging-area-tables-using-row-compacting.md
@@ -84,7 +84,7 @@ None.
 
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 
diff --git a/docs/design-patterns/design-pattern-generic-logical-partition-keys.md b/docs/design-patterns/design-pattern-generic-logical-partition-keys.md
@@ -44,7 +44,7 @@ If the ETL load will be doing a lookup in the target table, consider using the p
 Consider using the partition keys as part of the index in the target table to return results more quickly from the target table when doing lookups.
 If one of the partition streams fails, only the failed stream needs to be re-run. Existing streams do not need to be re-run if they have succeeded.
 
-## CConsiderations and consequences
+## Considerations and consequences
 In some cases there is no useable field in the source data that can be used as part of the logical key. In this case, a character attribute can be used to determine the logical partition. However, the selected field must still form part of the natural key of the source file so that there are no processing errors due to records being processed multiple times within the same run.
 Known uses
 Any table that requires stream loading due to big data sets.
diff --git a/docs/design-patterns/design-pattern-generic-managing-multi-temporality.md b/docs/design-patterns/design-pattern-generic-managing-multi-temporality.md
@@ -39,7 +39,7 @@ After the Staging Layer has been loaded the subsequent Integration Area ETL proc
 * End dates (Expiry Dates) are redundant and usually not required. These can be calculated from the Effective Date, if required. Given the fact that the Load Date/Time is fundamentally a technical value this is representing a time-variant view from the perspective of data arrival. Business users usually want to see information in a different way, which is why date/time series are often recalculated in the Presentation Layer following a different timeline.
 * Persistent Staging Area ETL processes typically do not process end-dates for performance purposes. In this case the Load Date/Time is inserted with each record as time interval as part of the Primary Key (thus acting as effective date).
 
-## CConsiderations and consequences
+## Considerations and consequences
 * Dependencies that are introduced by the loading strategy must be kept in mind. For instance: Integration Layer processes should be completed before the next Staging Layer ETL runs. If not, the new batch might overwrite any values in the Staging Area table and the wrong date/time will be used. This is one of the reasons why the standard Batch process includes both the Staging and Integration ETL processes.
 * Decoupling Data Warehouse timelines with process control (system date/times) means that the ETL will provide the same results regardless of when it is executed.
 
diff --git a/docs/design-patterns/design-pattern-generic-referential-integrity.md b/docs/design-patterns/design-pattern-generic-referential-integrity.md
@@ -35,7 +35,7 @@ Every Data Warehouse table contains a predefined set of metadata attributes, whi
 
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 TBD
 
diff --git a/docs/design-patterns/design-pattern-generic-types-of-history.md b/docs/design-patterns/design-pattern-generic-types-of-history.md
@@ -118,7 +118,7 @@ DWH Key	| Logical Key | Name | Current Name | Colour | Start date | End date
 * Avoid using NULL in the end date attribute of the most recent record to indicate an open / recent record date. Some databases have troubles handling NULL values and it is best practice to avoid NULL values wherever possible, especially in dimensions.
 * Depending on the location in the Data Warehouse either tables or attributes may be defined for a specific history type. For instance, defining a table as SCD Type 2 means that a change in every attribute will lead to a new record (and closing an old one). In Data Marts the common approach is often to specify a history type per attribute. So a change in one attribute may lead to an SCD Type 2 event, but a change in another one may cause the history to be overwritten.
 
-## CConsiderations and consequences
+## Considerations and consequences
 Not applicable.
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-generic-using-checksums.md b/docs/design-patterns/design-pattern-generic-using-checksums.md
@@ -68,7 +68,7 @@ Design Pattern 028  Generic  Full Outer Join interfaces.
 
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 
diff --git a/docs/design-patterns/design-pattern-logical-core-business-concept.md b/docs/design-patterns/design-pattern-logical-core-business-concept.md
@@ -36,7 +36,7 @@ Core Business Concepts can be categorized into:
 
 A Core Business Concept is typically implemented as a 'Hub' table using Data Vault methodology.
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 N/A
 
diff --git a/docs/design-patterns/design-pattern-logical-natural-business-relationship.md b/docs/design-patterns/design-pattern-logical-natural-business-relationship.md
@@ -27,7 +27,7 @@ If there can be multiple different ways the same concepts can be related to each
 * A Natural Business Relationship is typically implemented as a 'Link' table using Data Vault methodology.
 * When working with multiple relationships between the same concepts, it is not advisable to 'type' these e.g. by adding a relationship type or identifier. Instead, it is preferred to model this as separate relationships.
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 N/A
 
diff --git a/docs/design-patterns/design-pattern-presentation-layer-using-views.md b/docs/design-patterns/design-pattern-presentation-layer-using-views.md
@@ -31,7 +31,7 @@ Another use case for view is for virtualising the Presentation Layer. As all gra
 ## Implementation guidelines
 
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-staging-layer-joining-tables-in-the-staging-layer.md b/docs/design-patterns/design-pattern-staging-layer-joining-tables-in-the-staging-layer.md
@@ -35,7 +35,7 @@ The logic to create the initial (dummy) Satellite record can both be implemented
 When modeling the Hub tables try to be conservative when defining the business keys. Not every foreign key in the source indicates a business key and therefore a Hub table. A true business key is a concept that is known and used throughout the organisation (and systems) and is �self-standing� and meaningful.
 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.
 
-## CConsiderations and consequences
+## Considerations and consequences
 N/A
 
 ## Related Patterns
diff --git a/docs/design-patterns/design-pattern-staging-layer-landing-area.md b/docs/design-patterns/design-pattern-staging-layer-landing-area.md
@@ -72,7 +72,7 @@ The structure of the Staging Area therefore is the same as the source table, but
 | Upstream Hash Values     | Optional                | Character(32), when using   MD5 – not null            | Any pre-calculated hash values one may like to add to optimize upstream parallel loading (i.e. pre-hashing business keys), | Hash <>                   |
 | <source attributes>      | Required                | According to data   type  conversion table - nullable | The source attributes as available. Note that if a primary hash key is not used the natural key (source primary key) needs to be set to NOT NULL. All other attributes are nullable. | N/A                       |
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 * Resolving the Record Source ID will be done in the Integration Layer because disk space is less an issue in the Staging Layer. 
 * Adding key lookups in the Staging Area will also overcomplicate the ETL design and negatively impact performance. Alternatively is can be discussed to hard-code the identifier instead of the Source System name (as the RECORD_SOURCE). This reduces the requirement for the key lookup but reduces visibility over the data.
diff --git a/docs/index.md b/docs/index.md
@@ -48,5 +48,5 @@ The pattern structure (Design and Solution Pattern layout) always is as follows:
 * **Applicability**, a listing of where this pattern can be expected to play a role.
 * **Structure**, the main section with the pattern details.
 * **Implementation guidelines**, any references to how to implement this pattern (Design Patterns only). Note that the Solution Pattern is intended to explain the specifics in a technical context. This is meant to capture any generic topics.  
-* **CConsiderations and consequences**, meant to offer some alternative views and experiences as to what it means to take a certain decision.
+* **Considerations and consequences**, meant to offer some alternative views and experiences as to what it means to take a certain decision.
 * **Related patterns**, any references towards further reading and related content.
diff --git a/docs/solution-patterns/solution-pattern-SQL-Server-Family-CDC-and-replication.md b/docs/solution-patterns/solution-pattern-SQL-Server-Family-CDC-and-replication.md
@@ -47,7 +47,7 @@ The newly created CDC table is created under the CDC schema as part of the Syste
 
 ## Implementation guidelines
 
-## CConsiderations and consequences
+## Considerations and consequences
 
 This approach requires changes to the source systems, which may not always be possible or allowed. It has to be verified if you are allowed to install the publisher agent on the source system.
 
diff --git a/docs/solution-patterns/solution-pattern-data-modeling-presentation-layer.md b/docs/solution-patterns/solution-pattern-data-modeling-presentation-layer.md
