Keine Zeitreise ohne Paradoxon… Temporal Support in DB2 for i – Teil III: Herausforderungen

4. Dezember 2017 | Von admin | Kategorie: Programmierung, Software Development + Change Mgmt.

Ganz ohne Nebenwirkungen sind Zeitreisen durch die Datenbank erwartungsgemäß nicht möglich. Ein Paradoxon der besonderen Art lauert in einem völlig anderen wissenschaftlichen Bereich: der Juristerei. Die europäische Datenschutzgrundverordnung (DSGVO), die es ab dem 25. Mai 2018 einzuhalten gilt, stellt neue Anforderungen unter anderem an die Datenbank.

Read Offline:

Download PDF

Download ePub

c Burgy Zapp

von Patrick Arnold

Temporal Support (TS) kann diese zwar zum Teil erfüllen, in anderer Hinsicht steht dieses Feature aber im Widerspruch zu den Zielen der genannten Verordnung. Zusammen mit Row and Column Access Control (RCAC) lässt sich aber auch diese Hürde überwinden.

Die theoretischen Hintergründe zur temporalen Datenhaltung sowie der praktische Einsatz des Temporal Supports am Beispiel wurden in den ersten beiden Teilen dieser Artikelserie behandelt. Am Ende des zweiten Artikels (Die Zeitreise beginnt… : Temporal Support in DB2 for i – Teil II: Einrichtung und Nutzung) wurde bereits eine der großen Herausforderungen angesprochen, die es zu bewältigen gilt, wenn TS auch für bestehende, DDS-basierte Anwendungen genutzt werden soll.

Teil III erläutert nun diese Level-Check-Problematik und stellt mögliche Lösungsansätze vor. Anschließend werden relevante Neuerungen der DSGVO in Hinblick darauf beleuchtet, warum eine systemseitige Historisierung nicht unbedingt konform mit den Zielen dieses Regelwerks geht und wie RCAC Abhilfe schaffen kann.

Level-Check-Fehler

Eine DDS-definierte Datei besitzt einen eindeutigen Record Format Level Identifier (Formatebenen-ID). Dieser 13 Byte große String wird beim Kompilieren der Datei wie ein Hashwert (Fingerabdruck) generiert. Wenn sich nun eine Datenbankdatei durch Hinzufügen der notwendigen TS-Felder ändert („TS“-Feld in Abbildung 1), ändert sich auch die zugehörige Formatebenen-ID. Ein Programm („SW“ in Abbildung 1), das diese Datei nutzt, bricht mit einem Level-Check-Fehler (CPF4131) ab, falls die ID von der zum Kompilierungszeitpunkt des Programms gültigen ID abweicht. Dieses Verhalten ist grundsätzlich erwünscht, da es der Gewährleistung der Datenintegrität dient.

Der Record Level Format Identifier einer Datei lässt sich per Display File Description (DSPFD) in Erfahrung bringen. Die Integritätsprüfung kann beispielsweise bei einer physischen Datei über das Kommando CHGPF FILE(<Datei>) LVLCHK(*NO) deaktiviert werden. Dies sollte aber nur vorübergehend und nur zu Testzwecken geschehen, ansonsten wird davon dringend abgeraten.

Abb. 1: Level-Check-Fehler

Lösungsansätze

Die komfortabelste Möglichkeit, den genannten Laufzeitfehler zu beheben, ist es, die Anwendung nach Änderung der verwendeten Datei neu zu kompilieren. Das ist aber nur möglich, wenn alle dafür notwendigen Sourcen vorhanden sind.

Weiterhin kann die DDS-definierte Datei in eine SQL-Tabelle konvertiert werden. Dieser Schritt bietet sich an, da er den Modernisierungsgedanken der Datenbank seitens IBM unterstützt und SQL mehr Flexibilität – insbesondere auch beim Hinzufügen von Spalten – bietet. Hierfür kann die Stored Procedure GENERATE_SQL genutzt werden. Über Datenbank => Schemas in IBM i Access Client Solutions (ACS) lässt sich diese Funktion per Rechtsklick auf eine beliebige Datenbankdatei ausführen (siehe Abbildung 2).
Eine weitere Alternative stellt die Verwendung des Surrogate-Ansatzes dar. Dabei wird die ursprüngliche Datei durch eine logische Datei mit identischer Felddefinition, identischem Namen und identischer Feldebenen-ID ersetzt, die dann auf die um die TS-Felder erweiterte und umbenannte Ursprungsdatei referenziert.

Abb. 2: Konvertierung per Generate SQL

Abbildung 3 stellt die um Surrogates erweiterte Abbildung 1 dar. Das Programm (SW) greift nun nicht mehr auf die veränderte physische Datei (PF|TS) zu, sondern auf die neue logische Datei (LF), deren Definition dem ursprünglichen Physical File (PF) entspricht und auf die umbenannte und mit TS-Feldern versehenen Datei (PFs|TS) referenziert. Die Formatebenen-ID der neuen logischen Datei entspricht der ID der ursprünglichen physischen Datei. – Das Programm läuft damit ohne Recompile. Abbildung 3 zeigt weiterhin die zugehörige History Table (HT|TS).

Abb. 3: Einsatz der Surrogates

Datenschutzgrundverordnung

Die DSGVO an dieser Stelle vollständig abzuhandeln, würde den Rahmen der Artikelserie sprengen. Weiterhin sei angemerkt, dass dieser Abschnitt keine Rechtsberatung ersetzt und keinen Anspruch auf Richtigkeit oder Vollständigkeit erhebt.

Wichtige Neuerungen der DSGVO stellen – neben den Grundsätzen – einerseits die Rechte der von der Datenverarbeitung betroffenen Person dar, andererseits die umfangreichen Verpflichtungen der für die Verarbeitung verantwortlichen Stelle.

Sie müssen sich als Abonnent anmelden um den hier fehlenden Teil des Inhalts zu sehen. Bitte Login für Zugriff.

Noch nicht Abonnent? Sonderaktion nutzen.

Detaillierte Informationen liefert das RCAC-Redbook unter:

http://www.redbooks.ibm.com/abstracts/redp5110.html t

Über den Autor

Patrick Arnold hat in Darmstadt Informatik studiert und als IT-/Netzwerktechniker gearbeitet. Die dabei erlernten Fähigkeiten setzt er nun bei der All for One Steeb AG im Fachbereich DCW ein, um neue Technologien, wie Node.js und Temporal Support, und deren Nutzen für die Stakeholder zu erkunden. Dabei legt er Wert auf Verständlichkeit; allzu trockene Inhalte lösen bestenfalls Schlafprobleme, die bei seiner Affinität zu gutem Kaffee doch aber gewollt sind. Als Kind der 80er kennt er zwar die besten Zeitreisefilme, hatte im allgemeinen Informatikstudium und als Android-Nutzer aber kaum Berührungspunkte zur „i-Welt“. Dank Vorlesung und Bachelorarbeit bei Manfred Sielhorst hat sich das aber geändert. Über Feedback und Fragen freut sich der Autor immer unter: patrick.arnold (ät) all-for-one.com.