Regeln für die Selektion von Linkrelationen

Ab Version 2025.6 unterscheiden wir die Behandlung von "normalen" und "reflexiven" Relationen.

Definition

Reflexive Relationen sind Relationen zwischen zwei gleichen Entitäten.
Bei diesen muss dann sowohl die Hin- als auch die Rückrichtung einzutragen werden.

Relationen

• Es gibt Standard-Linktabellen, die keine zusätzlichen Relationsinformationen halten.

• Es gibt attributierte Linktabellen, die zusätzliche Relationsinformationen enthalten.

Eindeutigkeit

Einträge zwischen Relationen sind eindeutig zu halten.

• Auf „normalen“ Standard-Linktabellen (also Linktabellen ohne zusätzliche Attribute zwischen zwei unterschiedlichen Entitäten) ist die Kombination aus MasterPk und SlavePk eindeutig, aktuell ist auch das Active-Flag zu berücksichtigen, siehe Abschnitt Active-Flag weiter unten.

• Auf attributierten Standard-Linktabellen (also Linktabellen mit zusätzlichen Attributen zwischen zwei unterschiedlichen Entitäten) ist die Kombination aus MasterPk und SlavePk eindeutig, aktuell ist auch das Active-Flag zu berücksichtigen, also gleich mit den „normalen“ Standard-Linktabellen.

  • Hier ist allerdings eine Klärung im PM anhängig, da der Kunde TEN gefragt hat, ob dies generell ermöglicht werden soll.

• Auf Reflexiven Relationen müssen Einträge mit Relationsattributen ebenfalls eindeutig sein, allerdings kommt hier noch das bzw. die Relationsattribute der RowModelMergerFields zum Tragen, diese bestimmen ebenfalls die Eindeutigkeit mit.
  Beispiel:
  Die Geschäftspartner KundeA und KundeB werden miteinander verknüpft.
  Wird die Verknüpfung KundeA als Mutter von KundeB eingetragen, darf keine zweite Verknüpfung mit dem Attribut Mutter erfolgen, da dies keine eindeutige Verknüpfung wäre. Damit ist implizit hinterlegt, dass KundeB Tochter von KundeA ist.
  Die Verknüpfung KundeB als Mutter von KundeA darf eingetragen werden, sie ist aber sehr wahrscheinlich fachlich falsch.

• Neu mit Version 25.6 auf reflexiven Relationen
  In diese Linktabellen ist sowohl die Hin- als auch die Rückrichtung einzutragen.
  Beispiel:

  • rAcAc

    • Datensatz 1: masterPk: myPk1 und slavePk: myPk2

    • Datensatz 2: masterPk: myPk2 und slavePk: myPk1

  • rCuCu

  • Datensatz 1: masterPk: myPk1, slavePk: myPk2 und RelationTypeKey: MUTTER

  • Datensatz 2: masterPk: myPk2, slavePk: myPk1 und RelationTypeKey: TOCHER

• Die Daten werden nach dem folgenden Muster in die Datenbank geschrieben:

  • Initiale Richtung (das ist bereits vor Version 25.6 so):

    • Der Pk des Datensatzes aus dem Hauptfenster wird in MasterPk geschrieben.

    • Der Pk des im Unterbereich zur Verknüpfung ausgewählten Datensatzes wird in SlavePk geschrieben.

    • Der gewählte RelationPk (z. B. MUTTER) wird in das entsprechende Feld geschrieben

  • Zusätzlich muss ab Version 25.6 noch die "Rückrichtung" geschrieben werden

    • Der Pk des im Unterbereich zur Verknüpfung ausgewählten Datensatzes wird in MasterPk geschrieben.

    • Der Pk des Datensatzes aus dem Hauptfenster wird in SlavePk geschrieben.

    • Der AssignedPk (TOCHER) aus der S_Keytab zum gewählten RelationPk (hier MUTTER) wird in das entsprechende Feld geschrieben.

Regeln über den DefaultSetter

Über den DefaultSetter kann geprüft werden, ob für die Relation spezielle Regeln gelten und ggf. noch Daten redundant in eine der beiden Tabellen geschrieben werden müssen

• Im Feld RelationName steht die Relation, die besondere Regeln enthält.

• Im Feld BelongingLookupField steht der Name des Feldes, zu dem die Regel gilt. (Die Kombination aus RelationName und BelongingLookupField ist eindeutig)

• Im Feld DefaultFlagInLinkTable ist das physische Feld benannt, in dem der Marker für die doppelte Persistenz gespeichert wird.

• In den Feldern DefaultFlagInMaster bzw. DefaultFlagInSlave sind die virtuellen Felder in der Anwendung benannt, wie sie in die jeweilige Entität delegiert werden.

• Im Feld RelationTypeKey ist das virtuelle Feld aus Sicht der Master-Entität benannt, falls es eines gibt. Das physische Feld kann über die V_Metadata selektiert werden
  Beispiel:
  select DelegatedToPhysField from v_metadata where AttributeName = 'EasementRoleCu.Easement'
  oder insgesamt:
  select DelegatedToPhysField from v_metadata where AttributeName in (select RelationTypeKey from DefaultSetter where RelationTypeKey is not null)

• Im Feld RemoveOldLink gibt es die Konfiguration TRUE, FALSE, PROPERTY
  TRUE bedeutet, dass ein zuvor existenter Link entfernt wird
  FALSE bedeutet, dass ein zuvor existenter Link beibehalten wird, das Flag DefaultFlagInLinkTable aber zurückgesetzt wird
  PROPERTY bedeutet, dass der Anwender entscheiden kann, welches Verhalten er auf dieser Relation wünscht

• Das Feld ClearOnlyRelation gibt an, ob bei einer Änderung der bestehenden Relation das Flag in den anderen Relationen zurückgesetzt werden muss:
  Beispiel:
  Ansprechpartner Unterbereich Adressen:
  Es sind zwei Adressen hinterlegt, eine ist als Postadresse und eine als Anzeigeadresse markiert. Im Standard ist ClearOnlyRelation in beiden Fällen (DefaultCoPeAd.rCoPeAd und LetterCoPeAd.rCoPeAd) auf true gesetzt.

Das bedeutet, dass beim Setzen des jeweiligen Flags das Flag in dem anderen Datensatz des Unterbereichs entfernt wird.

• RelationTypePk (ab Version 25.6)
  Zur Vorbelegung des RelationTypeKeys, in dem man den Pk eines Schlüssels hinterlegen kann, der dann in die Rolle der Relation geschrieben wird.
  Vor Version 25.5 konnte man das nur erreichen, indem man einen Standardwert auf das Relationsfeld setzt. Gibt es aber mehrere doppeltpersistente Felder auf derselben Relation, reichte dies nicht aus. 

Active-Flag

• Auf Relationen zwischen Entitäten, die Bewegungsdaten enthalten, dürfen inaktive Einträge gelöscht werden.
  Beispielsweise Aktivitäten zu Mitarbeitern (rEmAc), hier können inaktive Relations-Datensätze gelöscht werden, da diese Information nur selten relevant ist.

• Auf Relationen zwischen Entitäten, die System-Konfigurationen enthalten, muss geprüft werden, ob inaktive Einträge wieder aktiviert werden müssen, hier ist das Löschen der inaktiven Daten nicht erlaubt.
  Soll ein neuer Eintrag geschrieben werden, ist zu prüfen, ob ein inaktiver existiert und dieser ist dann wieder zu aktivieren
  Hier sind insbesondere diese Linktabellen zu nennen

  • rGrEm: Gruppen eines Mitarbeiters

  • rEmUn: Mandanten eines Mitarbeiters

  • rEmEm: Stellvertretungen eines Mitarbeiters

Statements

Statements zum Ermitteln von attributierten Felden, die im Zuordnungsbrowser angeboten werden (RowModelMergerFields)

Mit diesem Statement können die Attribute auf "reflexiven" Releationen ermittelt werden:

with sub_Linktable as (
	select lv1.RowPk as linkTable from lmdVarchar lv1, lmdVarchar lv2, lmdVarchar lv3
            where lv1.RowPk = lv2.RowPk and lv1.RowPk = lv3.RowPk and
                        lv3.Fieldname = 'LinkTable' and coalesce(lv3.c2, lv3.c1, lv3.c0) != 'NONE' and
                        lv1.FieldName = 'MasterTable' and lv2.FieldName = 'SlaveTable' and
                        coalesce(lv1.c2, lv1.c1, lv1.c0) = coalesce(lv2.c2, lv2.c1, lv2.c0)
)
select a.rowPk, coalesce(c2, c1, c0) as rowModelMergerField
from amdBoolean a, sub_Linktable t
where a.fieldname = 'RowModelMergerField'
and a.rowPk like '%.' || t.linktable
and coalesce(a.c2, a.c1, a.c0) = 1
order by t.linkTable

Mit diesem Statement können die Attribute auf allen Relationstabellen ermittelt werden, auch die auf "normalen" Tabellen.

with sub_Linktable as (
      select rowPk as linkTable from lmdVarchar where fieldname = 'LinkTable' and coalesce(c2, c1, c0) != 'NONE'
      )
select a.rowPk,
       coalesce(c2, c1, c0) as rowModelMergerField
from amdBoolean a, sub_Linktable t
where a.fieldname = 'RowModelMergerField'
  and a.rowPk like '%.' || t.linktable
  and coalesce(a.c2, a.c1, a.c0) = 1
order by t.linkTable