Polizei & IT | Informationstechnik für die Fachlichkeit (3)

Informationsmodell Merkmalsbedeutungen / „Datenfelder“

15. Juli 2013 | Von | Kategorie: DATENBANKEN

Sobald Fachlichkeit und technische Berater sich auf einen Satz von Objekttypen verständig haben, können sie an die Festlegung der Merkmale für jeden einzelnen Objekttyp gehen.

Was sind Merkmale?

Merkmale sind kleine Informationselemente, sozusagen Informationsatome, die mit einem Objekt verknüpft werden können. Das Objekt ist z.B. eine Person, ein Fahrzeug, eine Adresse, usw. Jedem Objekt kann man jeweils dazu passende Merkmale anhängen, wie den Familiennamen, den oder die Vornamen, das Geburtsdatum, die Fahrzeugfarbe, Postleitzahl, Straße und Hausnummer usw.
Machen Sie einen kleinen Selbstversuch: Stellen Sie ein leeres Glas vor sich hin. Mit dem Glas wollen Sie einer Person, mit der Sie nicht sprechen, Informationen über einen Mann mitteilen: Das Glas stellt das „Personenobjekt“ für diesen Mann dar. Um dies mitzuteilen, schreiben Sie am besten erstmal den Namen des Mannes auf das Glas, sowie den Objekttyp (hier also: Person). Dann nehmen Sie kleine Zettel zur Hand und schreiben ‚Merkmale“ drauf, z.B. „Götz“, „Mario“, „21.05.1991“, „1,73“ „braun“ (usw.). Dann werfen Sie alle Zettelchen in das Glas. Im Prinzip funktioniert das mit den Merkmalen und ihrer Zuordnung zu einem Objekt ganz genauso.

Allerdings ist das Verfahren noch nicht ganz perfekt. Denn wenn nun der Dritte kommt, das Glas zur Hand nimmt und die Zettelchen liest, wird er Fragen haben: Was bedeutet „21.05.1981“ im Zusammenhang mit dieser Person, was ist „Götz“, der Vor- oder Nachname und was soll „braun“ sein, die Haare, die Augen oder die Haut?!
Was bisher noch fehlt zu den Begriffen auf den Zettelchen, ist deren Bedeutung. Perfekt wäre es also, wenn auf den Zettelchen stehen würde …
Familiename: Götz
Vorname: Mario
Geburtsdatum: 21.05.1991
Körpergröße: 1,73
Augenfarbe: braun

Denn erst wenn zu jedem Merkmalsbegriff auch eine Bedeutung angegeben wird, sind die Merkmale für jeden Dritten eindeutig verständlich. Das gilt in besonderem Maße, wo Information erfasst wird für „Leser“, mit denen der Erfasser u.U. niemals Kontakt haben wird, was gerade in polizeilichen Informationssystemen und bei dem angestrebten umfangreichen Austausch zwischen solchen Systemen die Regel werden wird.

Wie werden die Merkmale mit ihren Objekten verknüpft?

In relationalen Datenbanksystemen, wie sie von jedem Fallbearbeitungssystem verwendet werden, bestehen Merkmale grundsätzlich aus Merkmalsbegriff und Merkmalsbedeutung. Wie die Merkmalsbedeutung mit dem Merkmalsbegriff verknüpft wird, dafür gibt es zwei unterschiedliche Methoden. Und hier kommt das Datenmodell ins Spiel, also die interne, physische Struktur der Tabellen in der Datenbank.

Datenbanken mit konventionellem Datenmodell verwenden viele unterschiedliche Tabellen: Jede einzelne wird so eingerichtet, dass sie Objekte eines ganz bestimmten Objekttyps speichern kann. Das Beispiel mit dem Glas könnten wir so gar nicht umsetzen: Eine konventionell modellierte Datenbank würde uns vielmehr kleine Regale hinstellen – eines für jeden Objekttyp. Und dann können wir schauen, ob es für unsere Merkmale mit den Zettelchen auch passende Regalfächer gibt. Für jedes Objekt wird eine Zeile (eng: row) verwendet und die Spalte = Regalfächer geben an, welche Merkmale für jedes Objekt gespeichert werden können: In die Spalte „Familienname“ kommt also der „Götz“ aus unserem Beispiel, in die Spalte Geburtsdatum das „21.05.1991“, in die Spalte Körpergröße das „1,73“ usw. Klingt nach einfacher Sache – ist es auch, wenn man in der Lage ist, vor Entwicklung und Inbetriebnahme der Datenbank abschließend festzulegen, welche Objekte und Merkmale gespeichert werden sollen. Und nicht nach mehreren Jahren Betrieb islamische Studenten mit einem Hang zu Flugstunden oder zwei Männer auf Fahrrädern in den Mittelpunkt von Ermittlungen rücken …

Datenbanken mit dem generischen Datenmodell sind in diesem Punkt wesentlich flexibler. Dort werden nämlich tatsächlich die Merkmalsbegriffe und die Merkmalsbedeutungen zu Pärchen zusammengefasst und jedes Pärchen in einem eigenen Speicherbereich hinterlegt. Dort stehen die Merkmale dann ganz ähnlich, wie in der kleinen Liste oben. Wenn ein solches Merkmalspärchen einem bestimmten Objekt zugeordnet wird, so wird ein „Link“ (heißt nichts anderes als „Zuordnung“) geschrieben, die aus dem Merkmal und der Id des zugehörigen Objekts besteht.

Woher da die Merkmalsbedeutungen kommen, fragen Sie?! Sie könnten von jedem Benutzer selbst vergeben werden. Da das etwas zeitaufwändig und unpraktisch wäre, hat es sich eingebürgert, dass ein Vorrat von Merkmalsbedeutungen mit der Datenbank zur Verfügung gestellt wird. Der technische Ausdruck für solche Vorratslisten ist „Thesaurus„, im wahrsten Sinne des ursprünglichen Wortes ein „Schatz“ von Merkmalsbedeutungen, der den großen Vorteil hat, dass man ihn jederzeit erweitern kann, auch wenn das System längst in Betrieb ist und dass damit keinerlei „Änderungs-“ oder „Programmieraufwand“ verbunden ist. Für solche Definitionen von Bedeutungen in der Informationstechnik hat sich übrigens auch der Begriff „semantisch…“ eingebürgert, andere sprechen von „Metadaten.“ [Bitte nicht verwechseln mit den „Metadaten“, die in den letzten Tagen im Zusammenhang mit der Überwachungspraxis in die Zeitungen gekommen sind. Dabei handelt es sich schlicht um die Faulheit oder Unwissenheit von Journalisten, den englischen Begriff „metadata“ zu übersetzen in den korrekten deutschen Begriff „Verbindungsdaten“.] Doch nun zurück zu den Merkmalen und dem, was Sie als Vertreter der Fachlichkeit beachten sollten, wenn Sie Zuarbeiten leisten zur Erstellung des Thesaurus der Merkmalsbedeutungen / der Metadaten / der Semantik des neuen Informationssystems:

Wie findet man geeignete Merkmalsbedeutungen?

Merkmalsbedeutungen findet man ganz einfach durch die Fragen

Welche Einzelinformationen werden benötigt, um ein Objekt dieses Typs zu identifizieren? (z.B. Familiename, Telefonnummer, KFZ-Kennzeichen, Kontonummer und Bankleitzahl, Ausweisnummer, usw.)

Welche Einzelinformationen werden benötigt, um ein Objekt dieses Type zu beschreiben?

Möglich ist auch die Frage: Welche Datenfelder wollen wir in einer Maske sehen, mit der ein Objekt dieses Typs erfasst wird? Oder Mit welchen Suchbegriffen (d.h. Merkmalen / Merkmalsbedeutungen) soll nach Objekten gesucht werden?!

Wiederholt vorkommende Merkmalsgruppen / „nachgeordnete“ oder selbstständige Objekttypen

Erfahrungsgemäß wird bei der Festlegung der Merkmalsbedeutungen noch einmal eine Revision der Objekttypen notwendig: Nehmen Sie das Beispiel der Person: In vielen Systemen braucht man zur Person auch deren Anschrift. Gehört nun die Gruppe der Merkmalsbedeutungen für eine Anschrift (also Postleitzahl, Ort, Straße & Hausnummer) zu denen für die Person? Und wenn ja: Muss dann die gleiche Gruppe von Merkmalsbedeutungen auch bei den juristischen Personen aufgenommen werden? Denn die haben ja auch einen Sitz bzw. eine Adresse? Und bei den polizeilich relevanten Ereignissen und Straftaten, weil die einen Ereignisort oder Tatort haben? Oder verwendet man konsequent einen eigenen Objekttypen „Ortsangabe / Adresse“ und erzeugt eine Beziehung zwischen dem jeweiligen Personenobjekt (bzw. Straftaten- oder Ereignisobjekt) und dem Adress-Objekt?

Den Endanwendern ist diese Frage in der Regel egal. Sie wollen Adressinformationen verwenden können, wo sie sie brauchen und so oft sie sie brauchen. Nicht so den Programmierern. Sie glauben, dass Beziehungen zwischen Objekten mehr Aufwand machen und daher raten Programmierer gerne mal zur wiederholten Einbettung solcher Merkmalstypen-Gruppen in die einzelnen Objekte. Nachteile für den Anwender: Der „darf“ dann an vielen verschiedenen Stellen suchen, wenn er später eine Adresse sucht.

Unser Tipp aus der Praxis lautet daher: Machen Sie alle Kandidaten zu eigenständigen Objekttypen, nach denen später gesucht werden kann und die einen eindeutigen Objektnamen erhalten können. Das gilt also z.B. auch für Personenbeschreibungen, für Bankkonten oder für Telekommunikationsadressen.

Objektnamensbildende Merkmale

Es ist ferner gute Praxis, dass für jedes Objekt ein Name gebildet wird, anhand dessen jeder Anwender dieses Objekt eindeutig erkennen kann. Der Objektname ist nämlich für den Anwender das, was die (datenbank-interne) Objekt-Id für die Datenbank ist: Eine Identifizierung, die in dieser Datenbank nur einmal vorkommt (=eindeutig) und anhand deren man bzw. das Datenbanksystem dieses Objekt von anderen Objekten des gleichen Typs unterscheiden kann. Diese Fähigkeit wird übrigens ‚Objektidentität‘ genannt.

Meist wird der Objektname gebildet, indem die Merkmalsbegriffe von dafür festgelegten Merkmalsbedeutungen/Datenfeldern aneinandergereiht werden. Für ein Objekt vom Typ Person zum Beispiel besteht ein solcher Objektname i.d.R. aus Familienname, Vorname und Geburtsdatum (ggf. noch Geburtsort). Für ein Objekt vom Typ Ortsangabe besteht der Objektname aus Ortsname, Postleitzahl, Straße und Hausnummer. Sie sehen an diesen Beispielen, dass man Objektnamen so zu bilden versucht, dass sie eindeutig werden, d.h. es für jedes Objekt (in der Wirklichkeit) einen eindeutigen Objektnamen im Informationssystem gibt.

Gerade für die Merkmale, die zur Bildung des Objektnamens herangezogen werden, macht es natürlich Sinn, für die auch eine Eingabepflicht zu definieren. Damit wird sichergestellt, dass ein Objektname immer „vollständig“ ist, d.h. aus den notwendigen Bestandteilen besteht.

Drillings- und Mehrlings-Merkmale

Die meisten Merkmale sind Zwillinge, d.h. sie bestehen aus einem Begriff mit seiner Bedeutung. Ein Datum ist das Geburtsdatum, eine Postleitzahl gibt den Zustellbezirk an, die Vorwahl ist das Ortsnetzkennzeichen für einen TK-Anschluss usw. Mitunter kommen jedoch Drillings- oder sogar Mehrlings-Merkmale vor. Personen können mehr als einen akademischen Abschluss(titel) haben: Prof., Dr. med., Ph. D. zum Beispiel.

Viele Informationssysteme und die zugehörigen Anwendungen sind nicht in der Lage, mit Drillingen oder Mehrlingen adäquat umzugehen. Gerade bei den konventionellen Datenmodellen wird das auch wirklich schwierig. Es gibt eben nur eine Spalte „Akademischer Titel“ und wenn man dort mehr als einen Begriff reinbringen will, muss man sich etwas einfallen lassen: In der Regel werden dann Regeln angeboten, wie z.B. die, dass mehrere Begriffe in das eine Feld geschrieben und voneinander durch ein Sonderzeichen (z.B. #) getrennt werden sollen. Bei der Eingabe mag das noch angehen. Die Gefahr ist jedoch groß, dass bei einer Suche/Abfrage etwas übersehen wird. Wenn in einem Feld für ‚weitere Vornamen‘ diese Begriffe stehen: „Maria#Nikolaus#Johann#Jacob#Philipp#Franz#Joseph#Sylvester“ (die Vorlage verdanken wir einem ehemaligen Bundesverteidigungsminister …) muss bei der Suche schon exakt mit Wildcards gearbeitet werden, damit der „Jacob“ oder „Philipp“ auch berücksichtigt werden.

Das generische Datenmodell tut sich mit solchen Mehrlings-Merkmalen viel leichter: Denn es spricht doch nichts dagegen, die Drillinge oder Mehrlinge in Zwillingen zu zerlegen und ein- und demselben Objekt erst den Zwilling „Akademischer Titel: Prof.“ und dann den Zwilling „Akademischer Titel: Dr. med“ zuzuorden und wenn es denn sein muss, noch viele weitere …

Notwendige Korrektur von Merkmalen

Ein Beschuldigter gibt ein Geburtsdatum an. Das erweist sich als falsch und muss korrigiert werden. Dumme Sache: Denn in einem konventionell modellierten Informationssystem gibt es nur ein Feld für das Geburtsdatum. Also wird üblicher Weise das zunächst eingetragene Geburtsdatum überschrieben mit dem neuen. Das ist polizeilicher Alltag, allerdings nicht unbedingt fachlich richtig: Denn die ursprüngliche Information geht verloren, was umso schlimmer ist, als diese Information bereits in Dokumenten verwendet oder an Dritte weitergegeben worden sein kann.

Bei Verwendung des generischen Modells ist dieses Problem leicht zu lösen: Man kann ja leicht ein weiteres Pärchen erzeugen, das aus der Bedeutung „Geburtsdatum“ und dem nun neuen Datum besteht und auch dieses Pärchen dem Personenobjekt zuordnen. Das bisherige, korrigierte Geburtsdatum bleibt erhalten, wird aber als „historisches“ Merkmal gekennzeichnet, das jederzeit wieder ans Licht geholt werden. So wird lückenlos nachvollziehbar wann was geändert wurde (und wer das getan hat).

Zeitlicher Bezug von Merkmalen

Nicht wenige Menschen wechseln die Haarfarbe. Autos werden umgespritzt. In solchen Fällen wäre es sinnvoll, einen zeitlichen Bezug angeben zu können: Wann war eine Person blond- bzw. rothaarig? Oder: Wann war der Wagen schwarz lackiert? Ein konventionell modelliertes System hat hier seine Grenze erreicht: Es gibt schlicht keinen Platz für diese Zeitangabe: Wo denn auch?! In der entsprechenden Spalte steht der eine, nur eine mögliche Begriff. Wo soll jetzt noch die Zeitangabe hingeschrieben werden, wann dieses Merkmal seine Gültigkeit hatte?! Das generische Modell hat es hier sehr leicht. Es erweitert nämlich einfach den „Link“, d.h. die Zuordnung zwischen Objekt und Merkmal und fügt dort den entsprechenden Zetstempel ein.
Gleiches gilt sinngemäßt auch für die nächsten Anforderungen …

Anforderungen aus den Polizeigesetzen müssen nicht länger ignoriert werden …

Das generische Modell bietet weitere „Alleinstellungsmerkmale“, wenn es um die Zuordnung zwischen Objekten und ihren Merkmale geht: Sie betreffen weitere wichtige fachliche, bzw. sogar gesetzliche Anforderungen:

Erstens kann man zu jeder Zuordnung zwischen Objekt und Merkmal eine Bewertung angeben: Wie sicher ist es und wie belastbar war die Quelle für die Information, dass Herr X. zu diesem Zeitpunkt blondhaarig war. Denn Sie, als Fachmann auf polizeilichem Gebiet und ich dürften doch darin übereinstimmen, dass die bisher geübte Praxis der Bewertung einer ganze Person eigentlich überhaupt nichts aussagt. Symbolhandlung, sozusagen …

Zweitens kann man besonders geschützte, personenbezogene Merkmale (Religionszugehörigkeit, sexuelle Orientierung u.ä.) auf diese Weise tatsächlich wirksam schützen, weil man sie technisch markieren und damit von einer Weitergabe oder Einsichtnahme durch Unbefugte ausnehmen kann.

Drittens kann man Übermittlungs- oder Verwendungsbeschränkungen aufnehmen, wie sie sich aus jedem Polizeigesetz ergeben: Besonders wichtig ist diese Fähigkeit beim heute so häufig beschworenen Informations“austausch“ zwischen polizeilichen Informationssystemen (, womit wohl eher die Informationsweitergabe gemeint ist). Nicht nur steht es deutlich in jedem Polizeigesetz, dass der „Lieferant“ auch zuständig ist für etwaig notwendige Korrekturen seiner Datenlieferungen beim Empfänger. Es dürfte, wenn Informationssqualität und -stimmigkeit überhaupt noch eine Rolle spielt, jedoch auch fachlich angezeigt sein nachvollziehen zu können, wann man welche Information an welchen Empfänger weitergegeben bzw. an das BKA übermittelt hat. Nur dann kann man die nämlich korrigieren oder die Löschung anzeigen …

Das sind drei wesentliche und überzeugende Argumente für die Verwendung des generischen Datenmodells und Antworten auf zwingende gesetzliche Anforderungen. Kann das System Ihrer Wahl das in gleicher Weise?! Oder ist es besser, auch in Zukunft weiterhin kollektiv die Augen zuzumachen und das Thema zu wechseln, wenn die Rede auf Anforderungen aus dem jeweiligen Polizeigesetz kommt?!

Kataloge für Merkmalsbegriffe

Und nun – endlich! endlich! – kommen wir zu dem Thema, für das hunderte von Mitarbeitern aus der polizeilichen Fachlichkeit schon tausende von Manntagen bei endlosen Dienstreisen, Besprechungen, bei der Sachbearbeitung im eigenen Büro und der Vorbereitung von Umlaufbeschlüssen verbracht. Worum ging es dabei?! Um Kataloge für Markmalsbegriffe! Diese Listen, um die immer wieder Glaubenskriege zu entbrennen scheinen zwischen den Befürwortern von Katalogen für nahezu alles und jedes, was man beschreiben oder im Sachverhalt angeben kann, weil damit angeblich die Informationsqualität gesteigert wird und den Anhängern der Überzeugung, dass ein gut ausgebildeter, fachlich kompetenter Polizist am besten selbst in der Lage ist, mit seinen eigenen Worten und Begriffen den Sachverhalt treffend wiederzugeben.

Zu diesem Thema gibt es ganz viel zu sagen. Wir wollen uns zunächst jedoch beschränken auf das, was fachlich im Rahmen unserer Reihe als nächstes dran ist: Ein genauerer Blick auf die Merkmalsbegriffe, den zweiten Teil eines Merkmals-Zwillings nach der Merkmalsbedeutung. Wenn ich nun einfach weiter schreiben würde, wird dieser Beitrag noch länger, als Ihnen gefällt und mir lieb ist: Daher darf ich Sie verweisen auf die Fortsetzung – bald – an dieser Stelle …

___________________________________________________________________________________________________

Dieser Beitrag ist Teil der Serie …

Informationstechnik für die Fachlichkeit

Sämtliche bisher erschienenen Beiträge der gleichen Serie

Teil 1: Daten- und Informationsmodelle
Teil 2: Entwicklung des Informationsmodell – Objekttypen
Teil 3: Entwicklung des Informationsmodells – Merkmalsbedeutungen / „Datenfelder“
Teil 4: Entwicklung des Informationsmodells – Merkmalsbegriffe und Kataloge
Teil 5: Was hat Informationstechnik mit den NSU-Ermittlungen zu tun?!
Teil 6: Wie kommt das Informationsmodell ins Datenmodell?
 

Schlagworte: , , , , , , ,

Schreibe einen Kommentar