Norbert Peters
Identifikation
Identifikation
Das halbe Leben besteht aus Identifikation, Authorisierung also Dinge, die benötigt werden um etwas eindeutig zu identifzieren. Diese sind meistens Objekte. So wird bei uns hier alles ein Objekt sein, ob wir es später als solches verwalten oder nicht.
Objekte sind unter anderem:
- Gegenstände, wie Auto, Maschinen, Häuser etc.
- Orte, Städte, Straßen
- Personen
- Gesellschaften wie Unternehmen, Krankenkassen, Finanzamt
- Zeiträume, Perioden
Wie kann nun eine solche Identifikation aussehen um dann wirklich eindeutig zu sein. Wir fangen hier an, dieses anhand von realen Datenstrukturen zu betrachten.
Systemanforderungen
Bevor wir uns nun mit Beispielen beschäftigten stellt sich die Frage, in welchem Rahmen wir eine Identifikation benötigen. Ist es in einer Applikation, die in einem Unternehmen geschlossen läuft, dann sind keine großen Diskussionen erforderlich. Wir wollen hier aber ein System schaffen, dass in einem öffentlichen Bereich Daten verwaltet, die in getrennte geschlossene Bereiche verwendet werde.
Ein Beispiel wären in Deutschland die Krankenkassen mit den Anschriften und Beitragssätzen. Diese stehen heute zwar Online zur Verfügung werden aber immer in die geschlossenen Systeme übernommen. Viefach wird dieses mit Integritätsgründen bei den Berechnungen und der Jounalisierung begründet. Ein Blick in die Fachwelt und der Entwickler muss es umsetzen. Eindeutige Identifikation hier hält die Möglichkeit offen, dass alle theoretisch mit denselben Daten umgehen und damit Fehler vermieden werden oder zumindest alle gleich sind und zentral bereinigt werden könnten. Über derartige Systemanfordern werden uns noch öfter begegnen.
Die Systemanforderungen setzen damit schnon mal übergreifende Eindeutigkeit voraus.
Schönes Beispiel eine Anschrift
Das Objekt einer Anschrift ist ein schönes Beispiel, da viele Dinge eine Anschrift haben.
- Personen
- Gebäude
- Gesellschaften
- Unternehmen
Alles Objekte, bei denen heute die Anschrift in vielen unabhängigen Applikationen als Text gespeichert sind. Wenn es hoch kommt, dann sind diese noch irgendwo mit Google Maps verknüpft. Klar, damit es bei der Erfassund dieser unmengen an Anschriften etwas einfacher geht und damit möglichst Schreibfehler verhinder werden, werden Straßenverzeichnisse eingebunden. Klar es ist so einfach im Laufe der Entwicklung im digitalen Bereich so entstanden. Würde nun eine Anschrift eine eindeutige Identifikation haben, dann müsste dem Objekt nur noch diese Identfikation zugeordnet werden.
Klar kann man mit der heutigen Technik auch schon viel selektieren und vereinfachen, dich denke aber, dass man einen gewissen Aufwand sparen kann wenn ein bisschen anders gedacht wird. Es wird sich natürlich bei der Anschrift auch die Fage des Datenschutzes stellen, aber was sich allein durch eine Anschrift zu einem Objekt (auch Person) herausgefunden werden kann ist schon enorm. Warum soll man hier nicht einen einfacheren Weg gehen, der sich auf Dauer bezahlt macht.
So betrachten wir eine Anschrift und gehen davon aus, dass viele Daten in der Anschrift wiederum Objekte sind. Eine Anschrift muss ggf. folgende Werte bereitstellen:
- Land (Staat)
- Bundesland (in Deutschland) Kantone (in der Schweiz) etc.
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Anschriftenzusatz
- Postfach Nummer
- Postfach Postleitzahl
- Postfach Ort
Nun kann ich diese Anschrift unter einer ID erfassen, in einer DatenTabelle zur Verfügung stellen. Damit hätte ich schon gewonnen, dass ich die Erfassung einheitlich machen kann, genauso wie die Plausibilitäten. Jedes Objekt hätte damit immer noch seine Anschrift. Denken wir ein wenig weiter. Eine Anschrift in dem heutigen Sinne ist die Definition eines Ortes auf unserer Welt. Die Anschrift läßt sich einfach mit GPS Daten darstellen (ohne Postfach, da dieses nur einen psotalichen Character hat). Google macht dieses heute ja.
Unter diesen Aspekten würde ich heute eine Anschrift zentral unter einer ID (UUID) ablegen und intern wieder in zwei Bereiche aufteilen
- ORT (als eigenes Ojekt)
- Hausnummer
- Anschriftenzusatz
- ORT-Postfach (als eigenes Objekt ORT?)
- Postfach
Ob nun einer Anschrift beide Bereiche zugeordnet werden oder ob es über eine Art ggf. zwei Anschriften gibt, werden wir an anderer Stelle diskutieren, da es hier in er erste Linie um die Identifikation geht.
Zusätzlich würde ich eine Art der Anschrift noch einfügen, damit man weiß um welche Art (Hauptanschrift, Zeitanschrift, Urlaubsanschrift etc.) es sich handelt.
Nachdem sich nun eine Anschrift aus zwei Orten und einigen Zusatzangaben besteht sollten wir nun uns mal so einen ORT betrachten und welche Informationen daran hängen.
Das Objekt, der Ort
Das Object ORT unterscheidet sich im Typ. Es gibt einen realen Ort (der auch über GPS definiert werden kann) und einen fiktiven Ort (ein Postfach, eine Box, etwas definiertes). Dieses sollten wir bei unserem Objekt beachten.
Damit sehen wir folgende Eigenschaften in einem ORT:
- Typ (real / fiktiv)
- Land (Staat)
- Bundesland (Staatsuntergliederung)
- Straße
- Postleitzahl
- Ort
Wir betrachten es nun unter dem Gesichtspunkt, dass unsere Orte in einem Land liegen. Dieses ist ein eigenes Objekt, da es für jedes Land eine vielzahl von Eigenschaften gibt (ISO Codes, Länderkennzeichen, Name, Nationalität, IBAN-Plausi, Mitglied im europäischen Raum, Währung etc.) .
Genauso betrachten wir das Bundesland ein Land hat Bundesländer (oder andere Staatsuntergliederungen). Dieses machen wir wir wieder in einem eigenen Objekt SUBSTAAT. Da dieses Objekt immer die Zuordnung des Landes hat. Würde es genügen im Objekt der Anschrift die SUBSTAAT.ID zuzuordnen.
Nun der Ort liegt immer in einem SUBSTAAT und hat damit die Werte des Landes und des Substaates. Also einen Schritt weiter und wir müssten nur die ORT.ID zuordnen um die Werte bis zu Land zu haben.
Nun nur noch die Straße in einem eigenen Objekt, diese ist ja dann immer in einem Ort. Damit würde die STREET.ID für die Bestimmung des Ortes genügen, wenn da nicht die Postleitzahl wäre, die ja innerhalb einer Straße zum Beispiel in Deutschland unterschiedlich sein kann. Daher würde bei mir die STREET eine Zuordnung des Ortes haben und die STREET.ID bezieht sich auf die Straße und Postleitzahl (als Key).
Klar es ist hier ein fachlich logischer Gedanke der in der Umsetzung sich dann nur auf die IDs und die Namen bezieht.
Die eindeutige Identifizierung
Wie wir am Beispiel unserer Anschrift sehen wird es bei übergreifender Anwendung nur dann gehen, wenn wir mit übergreifenden eindeutigen IDs arbeiten. Eine GUID (UUID) bietet hier die besten Voraussetzung und werden auch meist intern zur identifizierung von Objekten verwendet.
Wenn wir nun noch einen Schritt weiter gehen, dann hat ein Objekt (eine ID) ggf. eine Historie. Wir müssen uns dieses so vorstellen, dass dann jeder Status eines Objektes wiederrum ein eindeutiges Objekt darstellt. Demnach jedes Gültig-ab-Datum im Status eindeutig idenrifzierbar sein muss. Auch hier sind GUID (UUID) erste Wahl.
So gesehen wird es dann in der Logik recht einfach, wenn jede benötigte eindeutige Identifizierung durch eine GUID (UUID) erfolgt.
Mischen von Beständen
Nun ein weiterer Vorteil bei der Vorgehensweise über die GUID (UUID) besteht darin, das Bestände, zum Beispiel die Personaldaten von zwei Unternehmen bei einer Fusion einfach gemischt werden können, einfach rein in die DB-Tabelle und fertig. Es gibt keine Duplikate, selbst wenn Namen, Geburtsdatum etc. identisch wäre. Gäbe es dann, aus welchen Gründen auch immer, dann müsste man nur diese Sonderfälle bereinigen, was auch maschinell geschehen kann.
Dabei ist es auch möglich, Daten sicher getrennt zu verschiedenen Mandanten in einer DB-Tabelle zu haben und hier ein Übergang von einem zum Anderen Mandanten nur durch die Änderung der entsprechenden Mandanten Id erfolgen kann.
Dieses nur einige Punkte, die für eine systemübergreifende eindeutige Identifizierung sprechen. In späteren Beispielen wird es ersichtlich, wenn wir über die Strukturen reden.