Typo only c to C

Author: RoelantVos

1000_Design_Patterns/Design Pattern - Generic - Managing temporality by using Load, Event and Change dates.md

@@ -1,4 +1,4 @@
-# Managing temporality by using Load, Event and Change dates
+# Managing temporality by using Load, Event and Change dates
 
 ## Purpose
 This Design Pattern describes how and when dates and timestamps are generated by the Data Warehouse.
@@ -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).
 
-## Considerations 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.