Relationen

Beschreibung: Informationen zu Datenbank Relationen im Allgemeinen finden Sie unter https://de.wikipedia.org/wiki/Relation_(Datenbank)

Relationskonfigurationsdateien werden in folgenden Verzeichnissen gesucht:

${PROJ}\sql\relation
${PROJ}\sql.indi\relation
${PROJ}\sql.${HHENVDOMAIN}\relation

wobei ${PROJ} bei kaskadierenden Projekten für jedes der kaskadierenden Projektverzeichnisse steht.

Relationsdateien können folgende Namen haben:

fina = ${SOGRelationenVersion} // Zur Zeit: relv2

finap = ${SOGRelationenProjVersion} oder wenn nicht gesetzt: ${SOGRelationenVersion}

${fina}_base_cfg.xml
${finap}_proj_cfg.xml
${finap}_vorort_cfg.xml
${finap}_test_cfg.xml
${fina}_foreach_cfg.xml
${finap}_foreach_cfg.xml

Üblicherweise sollten die Dateien also liegen unter:

${PROJ}\sql\relation\relv2_base_cfg.xml
${PROJ}\sql.indi\relation\relv2_proj_cfg.xml
${PROJ}\sql.${HHENVDOMAIN}\relation\relv2_vorort_cfg.xml

Aufbau der Steuerdateien

<Relations>
    <RelationGroup Name="person">
      <Relation Table="f010" Fields="firma sa konto" Uniq="true" Master="true" />
      <Relation Table="f012" Fields="firma sa konto" Uniq="false" />
      <Relation Table="f092" Fields="firma sa konto" Uniq="false" />
      <Relation Table="f090" Fields="firma sa konto" Uniq="false" />
      <Relation Table="meta_kunde" Fields="firma sa konto" Uniq="true" />
    </RelationGroup>
    <Class Table="f010" ObjectClass="#Kundenstamm" />
    <Class Table="f012" ObjectClass="#Ansprechpartner" />
    <Class Table="meta_kunde" ObjectClass="NONE" />
</Relations>

Eine Relationsgruppe beschreibt einen Schlüsselbegriff, über den von einer Tabelle auf eine andere verwiesen wird.
In den Tabelleneinträgen kann jeweils für eine Tabelle festgelegt werden, welche Datenfelder zu dem Schlüsselbegriff gehören.

Die Angabe "Uniq" definiert, ob ein Datensatz über die Schlüsselfelder in der entsprechenden Tabelle eindeutig identifiziert wird oder nicht.

Die Angabe "Master" definiert, welche Tabelle der Relationsgruppe die führende ist. Das bedeutet, das andere Tabellen als "Referenzdaten" zu verstehen sind.
Dies wird für z. B. automatische Reorgfunktionen von Metadatentabellen genutzt. Dabei können Metadaten erst dann gelöscht werden, wenn kein Datensatz in einer per Relation verbundenen "Master" Tabelle mehr vorhanden ist. Beispiel: Metadaten zu Kunden können gelöscht werden, wenn keine Daten zu dem Kunden mehr in der Tabelle "f010" vorhanden sind.
Über "GetObjectNoExFunction" kann festgelegt werden, über welche interne Zugriffsfunktion der Datensatz gelesen werden soll. Dadurch können z. B. Konvertierungen von numerischen Werten in alphanumerische Zugriffsbegriffe vorgenommen werden.

Es können beliebig viele Relationsgruppen festgelegt werden.
Die Anzahl der Datenfelder innerhalb einer Relationsgruppe muss für alle definierten Tabellen identisch sein.

  <RelationGroup Name="land">
    <Relation Table="f010" Fields="firma land 0" Uniq="true" />
    <Relation Table="land" Fields="firma nr unr" Uniq="true" />
  </RelationGroup>

Aus technischen Gründen kann es notwendig sein, dass bei Zugriff auf eine Tabelle nicht alle Daten verfügbar sind. In diesem Fall können in der entsprechenden Definition Konstanten verwendet werden.
Über "Class" Hinterlegungen wird festgelegt, welche CSharp-Klasse innerhalb von ActiveSkin für die Tabellen verwendet wird.

  <RelationGroup Name="Lieferant">
    <Relation Table="f010" Fields="firma sa konto" Uniq="true" />
    <Relation Table="f030" Fields="firma 2 lf_nr" Uniq="false" Recht="lfident" />
  </RelationGroup>

Bei der Festlegung einer Relation kann zusätzlich eine durch Kommas getrennte Liste von Rechten angegeben werden. Sind ein oder mehrere Rechte angegeben, kann die Relation nur genutzt werden, wenn der Sachbearbeiter die entsprechenden Rechte besitzt.

Beispiel für eine Relation aus der f010 auf die f077 - Branchen Datensatz, hier mit einer fest eingestellten Sprache "ger":

</RelationGroup>

Weitere Attribute:

IgnoreRelationCheck

Legt fest, dass die Tabelle von einer Prüfung auf referenzielle Integrität ausgeschlossen werden soll. Dadurch werden Datensätze, zu denen es keine Master-Datensätze mehr gibt nicht im p508 - Datenqualitätsmanager (dqm) als Fehler dargestellt.

Hide

Kann genutzt werden, damit eine Relation einem Benutzer zur zur Auswahl angeboten wird.

Title

Legt den Anzeigenamen einer Relation fest. Die Angabe dieses Attributes ist nur bei Uniq="true" sinnvoll und wird ansonsten ignoriert.

Recht

Definiert ein SOG ERP Recht das zur Verwendung der Relation benötigt wird.

HelpUrl

Kann auf Gruppenebene genutzt werden um einen Hilfepunkt zu hinterlegen.

Erweiterte Syntax zur Definition von Relationsfeldern

Über die erweiterte Syntax zur Definition von Relationsfeldern können diesen weitere Attribute zugewiesen werden. Dies ist für wenige, besondere Verknüpfungen notwendig.

Zur Nutzung dieser Syntax legen Sie bitte "Field" Nodes anstelle eines "Fields" Attributs an, und definieren Sie die einzelnen Felder die zuvor unter "Fields" erwähnt waren, jeweils in einzelnen "Field" Nodes.

Die Reihenfolge der Definition legt dabei die Reihenfolge der Datenfelder bei der Verknüpfung mit den anderen Tabellen fest.

Mögliche Attribute der "Field" Node sind:

Fieldname

Name des Datenfelder in der aktuellen Tabelle.

Const

Ohne "Fieldname" Attribut wird ein konstanter Wert festgelegt, der für den Zugriff auf die anderen Tabellen der Relation an dieser Stelle eingesetzt wird. Mit "Fieldname" Attribut handelt es sich um eine Einschränkung des Zugriffs auf Datensätze, die in dem angegebenen Datenfeld den durch "Const" definierten Wert aufweisen. Der Datentyp einer Const-Angabe wird automatisch erkannt. Nutzen Sie einfache Anführungszeichen um Textkonstante zu definieren. z. B. 'V'

Convert

Definiert den Datentyp, der bei einem Zugriff auf andere Datensätze der Relationsgruppe für das aktuelle Feld verwendet werden soll. Wird benötigt, wenn die aktuelle Tabelle z. B. Daten in einem numerische Daten in einem Textfeld ablegt.

Format

Definiert das Datenformat, in dem der entsprechende numerische Wert in dem Textfeld der aktuellen Tabelle gespeichert ist. Beispiel: Die Kontonummern werden in der Tabelle f094 mit 8 Vorlaufnullen gespeichert.

Ordinal

Definiert die Reihenfolge der Verwendung der Datenfelder für den Zugriff auf die entsprechende GetObject Funktion der aktuellen Tabelle. Ohne Ordinal-Angaben wird die Reihenfolge der Datenfelder in der Fields-Definition oder festgelegt durch die Reihenfolge der "Field" Nodes verwendet. Die Feldreihenfolge für den Zugriff muss der Reihenfolge der Datenfelder im Datenhandbuch der Tabelle entsprechen.

Zur Definition eines Feldes muss mindestens ein Fieldname oder ein Const-Attribut (oder beide) angegeben werden.

Beispiel 1: Verknüpfung der Tabelle f094 mit der f010

Bei der Verknüpfung der Tabelle f094 ist es notwendig, dass Datenfeld "tnr", dass in der Datenbank als Textfeld existiert, für den Zugriff auf die anderen Tabellen der Relationsgruppe z. B. "f010" in einen numerischen Wert zu konvertieren. Dies kann durch Angabe eines "Convert" Attributes in der Field-Node von "tnr" erfolgen. Gleichzeitig wird hier das Format Attribut gesetzt, um auch den umgekehrten Weg von der f010 auf die f094 zu ermöglichen, bei dem die Kontonummern der f010 mit 8 Vorlaufnullen formatiert werden müssen.

</Relation>

Beispiel 2: Verknüpfung der Tabelle f374 mit der f039

Bei der Verknüpfung der Tabelle f374 z. B. mit der f039 stehe zwar alle benötigten Datenfelder zur Verfügung, die Datenfelder sind in der "f374" aber in einer anderen Reihenfolge definiert, als in anderen Tabellen.

Daher ist es hier nicht möglich, die in der "Fields" Anweisung definierte Reihenfolge der Datenfelder für das Anlesen eines f374 Datensatzes zu verwenden. Daher muss in diesem Fall über die erweiterte Syntax mit Hilfe von "Ordinal" Attributen die Reihenfolge der Datenfelder zum Anlesen des Datensatze festgelegt werden.

</Relation>

Die Ordinal-Anweisungen legen hier also folgende Reihenfolge fest: firma, lg, sa, art, lgp, partie

Diese Reihenfolge entspricht der Reihenfolge der Datenfelder im Datenhandbuch der f374.

Erweiterung von Relationsgruppen

Relationsgruppen können auch in z. B. projektspezifischen Konfigurationen erweitert werden.

Es ist also nicht notwendig bei der Einführung einer Metadatentabelle eine vollkommen neuen Relationsgruppe zu verwenden und dort auch bestehende SOG ERP Tabelle neu einzutragen.

Stattdessen kann durch Nutzung vorhandener Relationsgruppen eine Verknüpfung einer neuen Metadatentabelle mit allen bereits in der Gruppe enthaltenen Einträgen erreicht werden.

Beispiel:

</RelationGroup>

Fügt die Tabelle "meta_beispiel_kunde" der bestehenden Relationsgruppe "Person" hinzu. Damit kann die Metadatentabelle automatisch von jeder Personentabelle genutzt werden.

Festlegung von Klassennamen

Über "Class" Einträge wird festgelegt, mit welcher internen Verarbeitungsklasse SQL Tabellen verarbeitet werden.

Beschreibung von 1:n Relationen

1:n Relationen beschreiben Datenrelationen, die von einem Datensatz auf beliebig viele andere Datensätze verweisen.
1:n Relationen können nur in einem entsprechenden Kontext verwendet werden, in dem nicht nur ein Datensatz oder ein Datenfeld eines Datensatzes verwendet wird, sondern eine Liste von Datensätzen genutzt werden kann. z. B. bei der Definition von Untertabellen in einem ObjectList-Control, oder bei der Definition von Tab-Reitern mit Tabellarischen Inhalt innerhalb eines PropGrid2-Controls.

Die Definition von 1:n Relationen wird in den gleichen Konfigurationsdateien, wie die Definition von einfachen Relationen durchgeführt.
Sie hat folgenden Aufbau:

<Relations>
  <ObjectListRelationen>
    <Relation ClassName="f096" Table="f093" RelationName="Positionen" Title="Rechnungspositionen" Link="Rechnung"/>
  </ObjectListRelationen>
</Relations>

Als ClassName kann entweder ein Klassenname in der Form "#Klasse" oder ein SQL-Tabellenname verwendet werden.
RelationName definiert den Relationsnamen. Dieser Muss für eine Klasse eindeutig sein.
Link bezeichnet die RelationsGruppe, die die Verbindung der beiden Tabellen definiert.

Title ist der Anzeigename der Relation. Ist dieser nicht gesetzt, greift standardmäßig der RelationName.

Bei diesem Beispiel wird die Verbindung eines RechnungsLeitsatzes zu seinen Positionen beschrieben.

Ein Beispiel aus dem Bereich der Metadaten beschreibt die Verbindung von Kundenstammdaten auf Metadaten "meta_standorte".

  <Class Table="meta_standorte" ObjectClass="#meta_standorte" />
  <RelationGroup Name="Person">
    <Relation Table="meta_standorte" Fields="firma sa konto" Uniq="false" RelationName="Standorte"/>
  </RelationGroup>

  <ObjectListRelationen>
    <Relation ClassName="#Kundenstamm" Table="#meta_standorte" RelationName="Standorte" Link="Person"
              InitNew="sa=${m_sa} konto=${m_konto}" />
    <Relation ClassName="#Aufgaben" Table="#meta_standorte" RelationName="Standorte" Link="Person"
              InitNew="firma=${m_firma} sa=${m_ek_vk} konto=${m_konto}" InitNewCheckField="konto" />
  </ObjectListRelationen>

Durch "InitNew" wird die Vorinitialisierung des Metadatensatzes gesteuert, wenn dieser im Kontext eines Kundenstammes oder einer Aufgabe neu angelegt wird.
Durch "InitNew" wird ein entsprechender PropGrid2-Control veranlasst, einen "Neu" Button anzubieten.
Mit "InitNewCheckField" kann ein Datenfeld angegeben werden, dessen Inhalt daraufhin geprüft wird, ob das Anlegen eines neuen Datensatzes möglich ist, oder nicht. Ist der Inhalt des Datenfeldes leer, oder "0", kann kein neuer Datensatz angelegt werden.

Rechte

Bei der Festlegung einer Relation kann zusätzlich eine durch Kommas getrennte Liste von Rechten angegeben werden. Sind ein oder mehrere Rechte angegeben, kann die Relation nur genutzt werden, wenn der Sachbearbeiter die entsprechenden Rechte besitzt.

  <ObjectListRelationen>
    <Relation ClassName="f096" Table="f093" RelationName="Positionen" Link="Rechnung" Recht="repos" />
  </ObjectListRelationen>

Festlegung von zusätzlichen, programmierten Einschränkungen

    <Relation ClassName="f010" Table="f092" RelationName="Aufträge" Link="Person"
              UserAddition1="${fn:ref:sach.ErlaubteAbt}" UserAddition1Sql="#TABLE#.abt in ({0})"
              UserAddition2="${fn:ref:sach.ErlaubteVgSa}" UserAddition2Sql="#TABLE#.ek_vk in ({0})" />

Über die Funktion "UserAddition" kann eine zusätzliche, programmierte SQL-Bedingung eingefügt werden, die meist vom Sachbearbeiter abhängig, z. B. die für den Sachbearbeiter erlaubte Datenmenge einschränken kann.
Die Festlegung von "UserAddition{n}" definiert dabei einen Text, der als Bedingung gilt, ob die entsprechende Erweiterung generiert werden soll, oder nicht. Sie wird generiert, wenn der Text einen nicht leeren String erzeugt. Die Anweisung ergibt sich dann aus "UserAddition{n}Sql". Hier kann der Bedingungstext durch den Platzhalter "{0}" eingefügt werden.
Es sind beliebig viele UserAddtions möglich.
Verwenden Sie "#TABLE#" für den Namen der Tabelle innerhalb von "UserAdditionNSql", damit die Anweisung innerhalb von generierten Join-Anweisungen korrekt verwendet wird.

#relationen

Foreach-Relationen

Es gibt die Möglichkeit Relationen auf Basis von Wertelisten mit Platzhaltern zu generieren. Dazu steht ihnen an Relationsgruppen und Relationen innerhalb von ObjectListRelationen die Möglichkeit zur Verfügung, einträge zu generieren.

Die Quelle der Wertliste und der Möglichen Plaztzhalter sind foldende:
Attribut ForeachTable="true":
#TABLENAME# - Technischer Tabellenname

#TABLEUNIQKEY# - Technischer Name des Primärschlüssels, idR. key_1 oder id

Attribut ForeachAwl="NAME_DER_AWL":
#AWL_VALUE# - Schlüsselwert innerhalb der Auswahlliste

#AWL_REF_VALUE# - Referenzwert zum Schlüssel. Dieser sollte nur für Title genutzt werden.

</RelationGroup>

<RelationGroup ForeachAwl="vpinf.awl" Name="Verpackungsinfo_#AWL_VALUE#">

</RelationGroup>

<ObjectListRelationen>

</ObjectListRelationen>