Recent changes to Home

Home modified by Thiemo Kellner

Thiemo Kellner — Wed, 11 May 2022 20:09:52 -0000

--- v10
+++ v11
@@ -12,7 +12,7 @@
 #### Cons ####
 1. It is no strict relation. Assume there are new versions of a child but the parent does not change at the same time, you can find only one of the children directly coming from the parent. This holds true the other way round too.
 ### Propagation of versions to children ###
-Create for each patent version a child version - cascading and branching.
+Create for each parent version a child version - cascading and branching.
 #### Pros ####
 1. Remove one part of the first con of the database foreign key.
 #### Cons ####

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 18:29:28 -0000

--- v9
+++ v10
@@ -52,6 +52,6 @@
 The following shall be implemented as options probably in that order.

 1. Update child to new parent version
-* Surragte business key
+* Surrogate business key (don't yet think there is a useful generalisation for this with respect to historisation)
 * Propagate versions to children which obviates 1.
 * Propagate versions to parents.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 10:52:14 -0000

--- v8
+++ v9
@@ -45,9 +45,13 @@
 *  For hierarchical joins without filtering on on business and/or technical validity one gets all the versions.

 ## Solution ##
-In short, there is no one fits all solution. We start off with: Mandatory database foreign key to be able to get the relation for the database catalog.
+In short, there is no one fits all solution. We start off with:
+
+* Mandatory database foreign key to be able to get the relation for the database catalog.
+
 The following shall be implemented as options probably in that order.
+
 1. Update child to new parent version
-1. Surragte business key
-1. Propagate versions to children which obviates 1.
-1. Propagate versions to parents.
+* Surragte business key
+* Propagate versions to children which obviates 1.
+* Propagate versions to parents.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 10:50:34 -0000

--- v7
+++ v8
@@ -48,6 +48,6 @@
 In short, there is no one fits all solution. We start off with: Mandatory database foreign key to be able to get the relation for the database catalog.
 The following shall be implemented as options probably in that order.
 1. Update child to new parent version
-* Surragte business key
-* Propagate versions to children which obviates 1.
-* Propagate versions to parents.
+1. Surragte business key
+1. Propagate versions to children which obviates 1.
+1. Propagate versions to parents.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 10:50:08 -0000

--- v6
+++ v7
@@ -1,3 +1,4 @@
+[TOC]
 # Architecture #
 Implementation was started with the idea of creating cascading row triggers to handle row by row. The idea is that new records are thrown at the table as inserts or deletes. Updates will inhibited. 
 ## Glossary ##
@@ -44,10 +45,9 @@
 *  For hierarchical joins without filtering on on business and/or technical validity one gets all the versions.

 ## Solution ##
-In short, there is no one fits all solution. We start off with:
-* Mandatory database foreign key to be able to get the relation for the database catalog.
+In short, there is no one fits all solution. We start off with: Mandatory database foreign key to be able to get the relation for the database catalog.
 The following shall be implemented as options probably in that order.
-* Update child to new parent version
+1. Update child to new parent version
 * Surragte business key
 * Propagate versions to children which obviates 1.
 * Propagate versions to parents.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 10:38:39 -0000

--- v5
+++ v6
@@ -1,5 +1,4 @@
 # Architecture #
-
 Implementation was started with the idea of creating cascading row triggers to handle row by row. The idea is that new records are thrown at the table as inserts or deletes. Updates will inhibited. 
 ## Glossary ##
 Version: A version of the payload specifics for one business key of an entity resulting in a record in the entity's table.
@@ -12,6 +11,7 @@
 #### Cons ####
 1. It is no strict relation. Assume there are new versions of a child but the parent does not change at the same time, you can find only one of the children directly coming from the parent. This holds true the other way round too.
 ### Propagation of versions to children ###
+Create for each patent version a child version - cascading and branching.
 #### Pros ####
 1. Remove one part of the first con of the database foreign key.
 #### Cons ####
@@ -19,6 +19,7 @@
 * Leads - in combination with the next variant - to denormalisation even though technically in different tables.
 * Propagation leads to performance penalties.
 ### Propagation of versions to parent ###
+Create for each child version a parent version - cascading.
 #### Pros ####
 1. Remove the other part of the first con of the database foreign key.
 #### Cons ####
@@ -33,16 +34,20 @@
 1. Suffering from performance penalty but to a lesser extent than the creation of new versions.
 2. Infringement of the DWH rule not to alter any record but on technical level.
 ### Surrogate business key ###
-The surrogate business key is an artificial key to join more than one business key. E. g. two systems have their own primary key for a person but both carry the social security number. One can integrate those two systems by the social security number and create an artificial surrogate for the primary keys and the social security number - the surrogate business key.
+The surrogate business key is an artificial key to embrace versions of one business key into one artificial key and optionally to merge more than one business key. E. g. two systems have their own primary key for a person but both carry the social security number. One can integrate those two systems by the social security number and create an artificial surrogate for the primary keys and the social security number - the surrogate business key.
 #### Pros ####
 1. Possibly easier join conditions than on the original keys.
+2. For hierarchical joins it is possible to find the desired versions when filtering (joining) on business and/or technical validity.
 #### Cons ####
 1. Probably no database foreign key constraint on these columns possible.
-2. Additional effort for the data integration.
+* Additional effort with the data integration.
+*  For hierarchical joins without filtering on on business and/or technical validity one gets all the versions.

-* There are performance concerns with this approach.
-* Deletes need to be identified beforehand rendering the solution less smooth in cases where only knows snapshot.
-
-Solution proposal
----
-Provide an alternative mechanism using an after insert statement trigger, deny updates and deletes.  The inserted records need to store the transaction id of its insert transaction with the new records to be able to destinguish from previous inserts. With this records that need to be terminated can identified and can be terminated.
+## Solution ##
+In short, there is no one fits all solution. We start off with:
+* Mandatory database foreign key to be able to get the relation for the database catalog.
+The following shall be implemented as options probably in that order.
+* Update child to new parent version
+* Surragte business key
+* Propagate versions to children which obviates 1.
+* Propagate versions to parents.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 10:13:01 -0000

--- v4
+++ v5
@@ -5,7 +5,7 @@
 Version: A version of the payload specifics for one business key of an entity resulting in a record in the entity's table.
 ## Variants ##
 Can be combined with eachother.
-### Database foreign constraints ###
+### Database foreign key constraints ###
 #### Pros ####
 1. Relation is easily visible also in models
 * Query optimiser could use the information to get a better execution plan
@@ -25,12 +25,20 @@
 1. Introduction of artificial records bloating the table.
 * Leads - in combination with the previous variant - to denormalisation even though technically in different tables.
 * Propagation leads to performance penalties though to lesser extents than previous variant.
-### Update the child to the newest parent version ###
+### Update the child to the new parent version ###
+In case there is a new parent version, and the making of the new version does not get propagated to the children making there new versions too, one can update the children of the original parent to point to the new parent.
 #### Pros ####
+1. The "current" state gets reflected quite perfectly.
 #### Cons ####
+1. Suffering from performance penalty but to a lesser extent than the creation of new versions.
+2. Infringement of the DWH rule not to alter any record but on technical level.
 ### Surrogate business key ###
+The surrogate business key is an artificial key to join more than one business key. E. g. two systems have their own primary key for a person but both carry the social security number. One can integrate those two systems by the social security number and create an artificial surrogate for the primary keys and the social security number - the surrogate business key.
 #### Pros ####
+1. Possibly easier join conditions than on the original keys.
 #### Cons ####
+1. Probably no database foreign key constraint on these columns possible.
+2. Additional effort for the data integration.

 * There are performance concerns with this approach.
 * Deletes need to be identified beforehand rendering the solution less smooth in cases where only knows snapshot.

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 09:53:55 -0000

--- v3
+++ v4
@@ -4,21 +4,27 @@
 ## Glossary ##
 Version: A version of the payload specifics for one business key of an entity resulting in a record in the entity's table.
 ## Variants ##
+Can be combined with eachother.
 ### Database foreign constraints ###
 #### Pros ####
 1. Relation is easily visible also in models
 * Query optimiser could use the information to get a better execution plan
 #### Cons ####
-1. It is no complete relation. Assume there are new versions of a child but the parent does not change at the same time, you can find only one of the children directly coming from the parent. This holds true the other way round too.
+1. It is no strict relation. Assume there are new versions of a child but the parent does not change at the same time, you can find only one of the children directly coming from the parent. This holds true the other way round too.
 ### Propagation of versions to children ###
 #### Pros ####
-1. Remove the first con of the database foreign key.
+1. Remove one part of the first con of the database foreign key.
 #### Cons ####
-1. Introduction of artificial records bloating the tables
-* 
+1. Introduction of artificial records bloating the table.
+* Leads - in combination with the next variant - to denormalisation even though technically in different tables.
+* Propagation leads to performance penalties.
 ### Propagation of versions to parent ###
 #### Pros ####
+1. Remove the other part of the first con of the database foreign key.
 #### Cons ####
+1. Introduction of artificial records bloating the table.
+* Leads - in combination with the previous variant - to denormalisation even though technically in different tables.
+* Propagation leads to performance penalties though to lesser extents than previous variant.
 ### Update the child to the newest parent version ###
 #### Pros ####
 #### Cons ####

Home modified by Thiemo Kellner

Thiemo Kellner — Mon, 05 Mar 2018 09:46:34 -0000

--- v2
+++ v3
@@ -1,10 +1,34 @@
-Architecture
-===
-Implementation was started with the idea of creating cascading row triggers to handle row by row. The idea is that new records are thrown at the table as inserts or deletes. Updates will inhibited. The inserts then are examined if previous records need to be terminated and they get terminated. Deletes get converted to updates on previous record versions. 
-Concerns
----
+# Architecture #
+
+Implementation was started with the idea of creating cascading row triggers to handle row by row. The idea is that new records are thrown at the table as inserts or deletes. Updates will inhibited. 
+## Glossary ##
+Version: A version of the payload specifics for one business key of an entity resulting in a record in the entity's table.
+## Variants ##
+### Database foreign constraints ###
+#### Pros ####
+1. Relation is easily visible also in models
+* Query optimiser could use the information to get a better execution plan
+#### Cons ####
+1. It is no complete relation. Assume there are new versions of a child but the parent does not change at the same time, you can find only one of the children directly coming from the parent. This holds true the other way round too.
+### Propagation of versions to children ###
+#### Pros ####
+1. Remove the first con of the database foreign key.
+#### Cons ####
+1. Introduction of artificial records bloating the tables
+* 
+### Propagation of versions to parent ###
+#### Pros ####
+#### Cons ####
+### Update the child to the newest parent version ###
+#### Pros ####
+#### Cons ####
+### Surrogate business key ###
+#### Pros ####
+#### Cons ####
+
 * There are performance concerns with this approach.
 * Deletes need to be identified beforehand rendering the solution less smooth in cases where only knows snapshot.
+
 Solution proposal
 ---
 Provide an alternative mechanism using an after insert statement trigger, deny updates and deletes.  The inserted records need to store the transaction id of its insert transaction with the new records to be able to destinguish from previous inserts. With this records that need to be terminated can identified and can be terminated.

Home modified by Thiemo Kellner

Thiemo Kellner — Wed, 28 Feb 2018 07:40:21 -0000

--- v1
+++ v2
@@ -1,8 +1,10 @@
-Welcome to your wiki!
-
-This is the default page, edit it as you see fit. To add a new page simply reference it within brackets, e.g.: [SamplePage].
-
-The wiki uses [Markdown](/p/pg-scd/wiki/markdown_syntax/) syntax.
-
-[[members limit=20]]
-[[download_button]]
+Architecture
+===
+Implementation was started with the idea of creating cascading row triggers to handle row by row. The idea is that new records are thrown at the table as inserts or deletes. Updates will inhibited. The inserts then are examined if previous records need to be terminated and they get terminated. Deletes get converted to updates on previous record versions. 
+Concerns
+---
+* There are performance concerns with this approach.
+* Deletes need to be identified beforehand rendering the solution less smooth in cases where only knows snapshot.
+Solution proposal
+---
+Provide an alternative mechanism using an after insert statement trigger, deny updates and deletes.  The inserted records need to store the transaction id of its insert transaction with the new records to be able to destinguish from previous inserts. With this records that need to be terminated can identified and can be terminated.