Persistenzschicht
Die Persistenzschicht umfasst den Teil eines Backends, der den Datenbestand verwaltet. Sie kommuniziert hierzu in der Regel mit einer Datenbank und, mittels persistenten Entitäten, mit dem Anwendungskern. Der Aufbau der Persistenzschicht sowie ihre Kommunikation mit anderen Schichten ist in folgender Grafik dargestellt.
Die Vorgaben zur Persistenzschicht verfolgen mehrere Ziele.
- Einheitlichkeit der Verwendung von JPA
-
Die Konfiguration und Umsetzung der Persistenz geschieht nachvollziehbar über festgelegte Mechanismen und ist, auf ein IT-System bezogen, stets gleich.
- Einfachheit der Verwendung von JPA
-
Die Persistenzschicht muss leicht verständlich und wartbar sein. Dies umfasst die Definition des Persistenz-Klassenmodells sowie den Einsatz von JPA.
- Schmale, definierte JPA-Schnittstelle
-
Die Verwendung und Konfiguration von JPA soll isoliert und über eine schmale Schnittstelle erfolgen. Die Persistenzschicht soll auf JPA über die schmale Schnittstelle zugreifen und keine Geschäftslogik enthalten.
- Effizienz und Schnelligkeit der Persistenzschicht
-
JPA und die gewählte JPA-Implementierung müssen effizient und schnell arbeiten. Datenbank-Aufrufe sollen möglichst effizient sein. Unnötige und mehrfache Zugriffe sollen vermieden werden.
1. Fachkomponenten
Die Persistenzschicht gliedert sich, wie der Anwendungskern, in Fachkomponenten. Die Fachkomponenten der Persistenzschicht entsprechen vom fachlichen Schnitt her denen des Anwendungskerns. Sie beinhalten das Datenmodell (das heißt Modellkomponenten, Entitäten und Attribute) der fachlichen Architektur und bilden es auf der technischen Ebene ab.
Die Fachkomponenten des Anwendungskerns besitzen die Datenhoheit auf die entsprechenden Fachkomponenten in der Persistenzschicht. Nur die Fachkomponente mit Datenhoheit darf Änderungen an den jeweiligen persistenten Entitäten vornehmen.
Die Fachkomponenten bestehen aus einer Schnittstelle und den persistenten Entitäten. Sie kümmern sich ausschließlich um die Verwaltung persistenter Entitäten und beinhalten selbst keinerlei Geschäftslogik.
Die Schnittstelle der Fachkomponente beschreibt die Operationen, die zum Speichern und Lesen der Entitäten aus der Datenbank nötig sind. Sie besteht aus einer Menge von Spring Data Repositories. Der Name eines Repositories leitet sich von derjenigen Entität ab, die über das Repository verwaltet wird.
| Spring Data Repository | |
|---|---|
Schema |
|
Beispiel |
|
Der Zugriff auf die Datenbank aus dem Anwendungskern heraus erfolgt immer über diese Repositories. Die Repositories werden als Spring Beans in den Anwendungskern injiziert.
Persistente Entitäten bilden Geschäftsobjekte ab und werden in der Regel nach ihnen benannt.
| Entität | |
|---|---|
Schema |
|
Beispiel |
|
Die Menge aller persistenten Entitäten bildet das Persistenz-Klassenmodell. Die Vorgaben und Konventionen zur Persistenzschicht beschreiben gewünschte Eigenschaften des Persistenz-Klassenmodells sowie Verwendungsregeln.
2. Persistenz-Framework
Die Persistenzschicht kommuniziert in Richtung Datenbank auf Basis der Standards JDBC und SQL. In Richtung des Anwendungskerns stellt sie persistente Entitäten mittels Spring Data JPA bereit. Zur Umsetzung des objekt-relationalen Mapping verwendet die Persistenzschicht das Produkt Hibernate.
3. Transaktionssteuerung
Das Thema Transaktionssteuerung wird nicht im Rahmen der Persistenzschicht behandelt, da Transaktionen in der IsyFact über den Anwendungskern gesteuert werden.
4. Versionierung von Datenbankschemas
Die Struktur der Daten, die von einer Anwendung dauerhaft gespeichert werden, kann sich im Laufe des Lebenszyklus der Anwendung ändern. Das bedeutet, dass sich neben der Anwendung auch das Datenbankschema ändert. Die Anwendung und das Datenbankschema müssen zueinander passen.
Die Verwaltung von Versionsinformationen für ein Datenbankschema soll sicherstellen, dass die Anwendung und Skripte (zum Beispiel zur Datenmigration) erkennen können, ob ein Datenbankschema die erwartete Version hat. Zusätzlich sollen die Datenbankadministratoren nachvollziehen können, welche Änderungen am Datenbankschema bereits erfolgt sind.
Backends benutzen hierzu Liquibase.
| Vom bisherigen Verfahren (Eigenentwicklung) ist nur noch die manuelle Prüfung der Schema-Version im Baustein Util aus Gründen der Abwärtskompatibilität vorhanden. |
Falls es die Anforderungen erfordern, können mehrere Datenbankschemas zusammen versioniert werden. Dabei gibt es zwei mögliche Konstellationen:
-
Schema-übergreifende Versionierung innerhalb derselben Datenbank,
-
Datenbank-übergreifende Versionierung.
Eine Schema-übergreifende Versionierung innerhalb derselben Datenbank ist möglich. Bei der Aktualisierung auf eine aktuellere Version ist folgendes Vorgehen vorgesehen:
-
Aktualisierung der einzelnen Schemas,
-
Ausführung Schema-übergreifender Operationen.
Im Gegensatz zu Schema-übergreifender Versionierung wird von Datenbank-übergreifender Versionierung dringlichst abgeraten.
| Der IT-Grundschutz (M 4.71) sieht die Verwendung von Database Links, die für eine Datenbank-übergreifende Versionierung genutzt werden können, nur unter strengen Auflagen zulässig, die eine Verwendung erheblich erschweren. |
Unabhängig von der Lösung erschweren Datenbank-übergreifende Operationen die Fehlersuche im Falle einer fehlgeschlagenen Installation oder Aktualisierung wesentlich.
5. Historisierung
Historisierung (auch temporale Datenhaltung genannt) bezeichnet das Festhalten der zeitlichen Entwicklung von Daten beim Speichern in einer Datenbank. Für Datensätze sind zwei Arten der zeitlichen Betrachtung relevant:
-
Gültigkeitszeit: Der Zeitraum, wie lange ein Datensatz gültig ist. Während der Beginn der Gültigkeit meistens genau bekannt ist, so kann das Ende der Gültigkeit so lange unbekannt sein, bis der Datensatz ungültig wird.
-
Bearbeitungszeit: Der Zeitpunkt, zu der ein geänderter Datensatz in der Datenbank gespeichert wurde.
Das folgende Beispiel verdeutlicht beide Begriffe.
Eine Bescheinigung wird für einen festgelegten Zeitraum (Gültigkeitszeit) ausgestellt. Die Entscheidung darüber, die Bescheinigung auszustellen, wird vor Beginn ihrer Gültigkeit gefällt und in der Datenbank gespeichert (Bearbeitungszeit).
Eine Historisierung von Datensätzen wird durchgeführt, wenn Fragen über den Wert eines Datensatzes zu einem vergangenen Zeitpunkt beantwortet werden müssen (Beispiel: ob zu einem bestimmten Zeitpunkt eine Bescheinigung vorlag), oder wenn der Verlauf eines Wertes über die Zeit beobachtet werden muss (Beispiel: wann und warum die Bescheinigung ausgestellt bzw. nicht ausgestellt wurde).
5.1. Abgrenzungen
Die Historisierung grenzt sich wie folgt von den Themen Archivierung, Datensicherung, Protokollierung und Logging ab.
- Archivierung
-
Bei der Archivierung handelt es sich um die Aufbewahrung eines Datensatzes über eine längere Zeit hinweg. Dies ist meist aus rechtlichen Gründen notwendig zum Beispiel wegen gesetzlicher Aufbewahrungsfristen. Bei der Archivierung sind dementsprechend Randbedingungen wie Integrität, Unveränderlichkeit und Vertraulichkeit einzuhalten (siehe IT-Grundschutz BSI).
- Datensicherung (Backup)
-
Bei der Datensicherung handelt es sich um das redundante Aufbewahren von Datensätzen. Das Ziel ist es, bei Verlust oder ungewünschter Manipulation von Datensätzen diese Datensätze auf den gespeicherten Stand zurücksetzen zu können.
- Protokollierung
-
Ziel der Protokollierung ist das Nachvollziehen von Änderungen und Auskünften. Dazu werden je nach Bedarf die Suchschlüssel und Nettodaten von Aufrufen gespeichert.
- Logging
-
Beim Logging werden Notizen zu technischen Aufrufen innerhalb eines Systems oder zwischen Anwendungen in Dateien abgelegt. Das Logging hat einen technischen Fokus und dient in der Regel als Hilfsinstrument zur Fehlerbehebung.
5.2. Anforderungen & Festlegungen
Die beabsichtigte Nutzung der Historisierung lässt sich mit Blick auf die Referenzarchitektur zu Anforderungen verallgemeinern, die in diesem Abschnitt dargestellt werden.
Für die Historisierung von Datensätzen in einer Anwendung gelten folgende Anforderungen und Grundsätze:
-
Es dürfen nur solche Daten historisiert werden, die auch angezeigt werden.
-
Die Speicherung von historischen Daten wird durch individuelle Löschfristen von Datensätzen begrenzt.
-
Datensätze müssen beim Eintreten bestimmter Ereignisse komplett, das heißt inklusive aller historisierten Datensätze, gelöscht werden.
-
Für die meisten Daten ist eine Historisierung weder notwendig noch erlaubt. Dies ist durch Vorgaben des Datenschutzes und der Geheimhaltung begründet.
Diese Anforderungen führen zu folgender Architekturregel:
Mehr zur Konzeption und Umsetzung der Historisierung in der Persistenzschicht beschreibt die Unterseite Historisierung.