Informationstechnik für die Fachlichkeit (6)

Wie kommt das Informationsmodell ins Datenmodell?

27. August 2013 | Von | Kategorie: DATENBANKEN

Beitrag der Fachlichkeit: Das Informationsmodell

Die Fachlichkeit hat ihren wesentlichen Beitrag für die Entwicklung geleistet, indem sie Vorgaben gemacht hat für das Informationsmodell. Ergebnis ist

  • eine Liste mit allen Objekttypen, die in der Datenbank gespeichert werden sollen,
  • zu jedem Objekttyp eine Liste der Merkmalstypen, die benötigt werden, um die identifizierenden bzw. beschreibenden Merkmale für jeden Objekttyp zu erfassen, sowie
  • Aussagen zu den Beziehungen, die definieren, welcher Objekttyp mit welchem anderen Objekttyp verknüpft werden soll.

Die anstehende Aufgabe: Entwicklung des Datenmodells

Auf der Basis dieser Vorarbeiten werden nun die ITler tätig, um das Datenmodell einzurichten. Sie erinnern sich vielleicht an Teil 1 dieser Serie: Ein physisches Datenmodell (für eine relationale Datenbank) besteht aus den Tabellen, die notwendig sind, um
Objekte für sämtliche Objekttypen des Informationsmodells mit Merkmalen zu sämtlichen Merkmalstypen aus dem Informationsmodell zu speichern und die es erlauben, dass die notwendigen Verknüpfungen zwischen Objekten darin gespeichert werden können.

Alternativen der Datenbank-Modellierung

Wie man vorgeht, um das gewünschte Informationsmodell im physischen Datenmodell abzubilden, dafür gibt es grundsätzlich nur zwei Alternativen, nämlich

  • die konventionelle, spezifische Modellierung und
  • die generische Modellierung.

Der Unterschied in der Vorgehensweise liegt darin, wie das Informationsmodell im physischen Datenmodell (also in den zu erstellenden Tabellen) abgebildet wird. Daraus ergeben sich allerdings wesentliche Konsequenzen für die Vollständigkeit und Qualität der Information, die im jeweiligen Modell gespeichert werden können und dramatische Auswirkungen im Hinblick auf die Zeit und den Aufwand, den spätere Änderungen verursachen. Es ist objektiv nicht mehr nachvollziehbar, in welcher Weise dieser Aspekt bei der Entscheidung für polizeiliche Informationssysteme seit Jahren ignoriert wird.

Konventionelle Modellierung

Bei der konventionellen Modellierung wird individuell entwickelt, d.h. das es wird ein „Maßanzug“ erstellt, der exakt so bemessen wird, dass das zuvor definierte Informationsmodell darin abgebildet werden kann. Es wird dabei

  • für jeden Objekttyp eine eigene Tabelle eingerichtet,
  • innerhalb jeder Tabelle für jeden Objekttyp eine eigene Spalte eingerichtet für jeden Merkmalstyp, der dort gespeichert werden muss und
  • für jede (im Informationsmodell definierte) Beziehung zwischen jeweils zwei Objekttypen werden die entsprechenden Felder zur Aufnahme der Fremdschlüssel/Verweise in der jeweiligen Tabelle aufgenommen bzw. Linktabellen zwischen den beiden Objekte-Tabellen eingerichtet.

Bei konventioneller Modellierung ist das Informationsmodell sozusagen „fest verdrahtet“ im Datenmodell. Jede Änderung am Informationsmodell bedeutet daher eine Änderung am Datenmodell – und das zieht einen Rattenschwanz von Folge-Änderungen nach sich.

Jedes konventionelle Datenmodell ist untrennbar verbunden mit der Art des Inhalts („Semantik“) und der Struktur der Informationen, die darin gespeichert werden und somit eine individuelle Maßanfertigung für den spezifischen Einzelfall.

Generische Modellierung

Die generische Modellierung geht von der Grundannahme aus, dass sich das Informationsmodell ändert während der (meist langen) Laufzeit eines großen Datenbanksystems. Aus diesem Grund wird das Informationsmodell bei generischer Modellierung eben nicht „fest verdrahtet“ in der Struktur der Tabellen. Denn im generische Modell werden die Inhaltsdefinitionen strikt getrent von der Tabellenstruktur. Die zugrund liegende Überlegung ist etwas abstrakter: Sie geht davon aus, dass es in jedem Datenbanksystem drei Arten von Elementen gibt, die sich in ihrer internen Struktur unterscheiden, nämlich

  • Objekte
  • Merkmale und
  • Beziehungen zwischen Objekten

Für jedes dieser drei Elemente stellt das generische Modell jeweils eine entsprechende Tabelle bereit. Somit gibt es im generischen Modell also

  • eine und nur eine Tabelle für alle Objekte
  • eine und nur eine Tabelle für die Merkmale und
  • eine und nur eine Tabelle für die Verknüpfungen zwischen Objekten.

Das generische Datenmodell ist also vollkommen unabhängig vom Inhalt und der Struktur der Information, die darin gespeichert wird.

Die Struktur eines konventionellen Datenmodells

Ein konventionell modelliertes Datenmodell ist eine individuelle, spezifische „Maßanfertigung“ für einen bestimmten Einsatzzweck. In einer konventionellen Tabellenstruktur ist das (von der Fachlichkeit) zuvor definierte Informationsmodell „fest verdrahtet“, weil

  • für jeden Objekttyp eine eigene Tabelle eingerichtet wird
  • für jeden Merkmalstyp (innerhalb jeder Objekte-Tabelle) eine eigene Spalte
  • und für jede einzelne Verknüpfung zwischen zwei Objekten, die zuvor bedacht und definiert wurde wird eine entsprechende Verknüpfungsmöglichkeit in der Tabellenstruktur vorgesehen.

Jedes konventionelle Datenmodell ist also untrennbar verbunden mit der Art des Inhalts („Semantik“) und der Struktur der Informationen, die darin gespeichert werden.

Für jeden Objekttyp eine spezifische Objektetabelle

Die „feste Verdrahtung“ des Informationsmodells im Datenmodell beginnt bei der konventionellen Modellierung schon damit, dass für jeden Objekttypen eine eigene Tabelle angelegt wird. Ihr Zweck besteht darin, dass in der jeweiligen Tabelle nur Objekte eines ganz bestimmten Typs gespeichert werden können, also z.B. nur Personen oder nur Firmen oder nur Adressen oder nur Fahrzeuge usw.
Für jeden Merkmalstyp (z.B. Vorname, Familienname, Geburtsdatum, usw.) zum jeweiligen Objekttyp gibt es eine Spalte in der jeweiligen Tabelle, wobei die Spalte vorgibt, von welcher Merkmalsbedeutung die Begriffe sein sollen, die in einer Zelle der jeweiligen Spalte gespeichert werden. An sich gleiche Begriffe, wie z.B. „Schuster“ stehen also für einen Familiennamen, wenn sie in der Spalte für Familiennamen abgelegt werden und für einen Beruf, wenn sie in der entsprechenden Spalte gespeichert werden.

Für jede Verknüpfungen zwischen Objekten eine spezifische Lösung

Im nächsten Schritt der Modellierung sind die Verknüpfungen zwischen Objekten zu berücksichtigen: Und dafür gibt es drei mögliche Varianten, je nach der „Kardinalität“ der Verknüpfung. (Die Kardinalität gibt an, wie oft ein Objekt vom Typ A mit einem Objekt vom Typ B verknüpft werden kann bzw. muss):

1:n-Verknüpfungen, sind solche, wo ein Objekt von einem Typ A (z.B. Adresse) verknüpft werden soll mit einem oder mehreren Objekten (meist) eines anderen Objekttyps B (z.B. Person oder Firma oder Straftat). Dazu muss in der Tabelle für den jeweiligen Objekttyp B eine zusätzliche Spalte eingerichtet werden für den „Fremdschlüssel“, d.h. den Verweis auf ein Objekt vom Typ A (Adresse), das mit einem Objekt vom Typ B verknüpft wird. Auf diese Weise kann man die so genannten 1:n-Beziehungen im Datenmodell unterbringen (sie heißen so, weil ein Objekt vom Typ A (hier: Adresse) mit n Objekten vom Typ B verbunden werden kann, praktisch gesagt also diverse Personen, die in einem Mehrfamilienhaus an der gleichen Adresse wohnen.

1:1-Verknüpfungen sind solche, wo ein Objekt vom Typ A genau eine Beziehung mit einem Objekt vom Typ B (oder dem gleichen Typ A) aufweist und umgekehrt. Monogame Partnerbeziehungen zwischen Personen wären so ein Beispiel, denn Person A1 ist verheiratet mit Person A2 und (umgekehrt ist) Person A2 verheiratet mit Person A1.
Um solche Verknüpfungen abzubilden, wird in jeder Tabelle jeweils eine Spalte eingerichtet, um den Fremdschlüssel aufzunehmen, der auf das verknüpfte andere Objekt verweist. Und selbstverständlich muss man auch hier ganz genau definieren, auf welche anderer Tabelle (und deren Fremdschlüssel) sich diese Verknüpfung bezieht.

m:n-Verknüpfungen sind die dritte Variante für Verknüpfungen zwischen Objekten. Sie werden verwendet, wenn Objekte eines Typs beliebig oft mit Objekten (des gleichen Typs oder) eines anderen Typs verknüpft werden können sollen.
Beispiel: Personen können Gesellschafter / Aktionäre sein von Firmen. Jede Person kann jedoch an beliebig vielen Firmen beteiligt sein. Umgekehrt kann jede Firma beliebig viele Personen als Gesellschafter haben. Für solche m:n-Verknüpfungen muss zwingend eine so genannte „Linktabelle“ eingerichtet werden. Sie besteht aus mindestens zwei Spalten, von denen die eine den Fremdschlüssel/Verweis für (in unserem Beispiel) die Firmen aufnimmt und die zweite den Fremdschlüssel/Verweis für (in unserem Beispiel) die Gesellschafter. Für jede Paarung aus Firma und Gesellschafter wird dann ein entsprechendes Pärchen = ein Datensatz in diese Linktabelle geschrieben. Sollte es nun eine weitere m:n-Verknüpfung geben, z.B. weil Firmen verschiedene Adressen haben können bzw. an einer Adresse = Standort verschiedene Firmen ansässig sein können, so wäre dafür eine weitere m:n-Linktabelle einzurichten usw.

Wie kommt das Informationsmodell in ein konventionelles Datenmodell?

Im Falle der konventionellen Modellierung ist erheblicher Aufwand nötig für die „Entwicklung“ eines physischen Datenmodells. Was dabei herauskommt, ist so einzigartig, wie ein Maßanzug zum Zeitpunkt der Anprobe. Jedesmal, wenn sich in der Zukunft der „Körper“, also das Informationsmodell ändert, wenn es zunimmt oder abnimmt oder auf Informationsmodelle vonPartnersystemen angepasst werden muss, müssen die Entwickler wieder ran: Das Datenmodell muss geändert werden und in Folge davon auch alle Programme, die auf diese Datenbank zugreifen.
Das ist sicherlich ein wünschenswerter Zustand für jeden, der auf diese Weise sein Geld verdient.
Es ist allerdings der schlechteste, mögliche Zustand für jeden Betreiber, der daran gemessen wird, ob sein Informationssystem eigentlich die Fragen beantworten kann, die Richter, Staatsanwälte und Rechtsanwälte, bzw. Geschädigte und Beteiligte nach einem „Fall“ so stellen. Denn ein solcher „Maßanzug“ kann nicht darauf angelegt sein, sämtliche Informationen zu speichern, die das Leben (und damit ein Kriminalfall) so zu bieten haben. Wenn zusätzlich auch noch auf eine zentrale Linktabelle für die Verknüpfung von Objekten verzichtet wird, ist vorprogrammiert, dass an sich vorhandene Zusammenhänge nicht erfasst und damit später auch nicht ausgewertet und erkannt werden können.

Größenordnungen …

In polizeilichen Informationssystemen werden i.d.R. nicht mehr als 20 verschiedene Objekttypen verwendet. Daraus werden bei konventioneller Modellierung also mindestens 20 verschiedene Objektetabellen. Zu jedem dieser Objekttypen werden zwischen 10 und 30 Merkmalstypen verwendet, das ergibt im Schnitt also 20 Merkmalstypen pro Objekttyp und somit 400 verschiedene Spalten für Merkmale.

Wenn man die Möglichkeit vorsieht – was für Fallbearbeitungssysteme das absolute Muss sein sollte – dass jedes Objekt mit jedem anderen Objekt beliebig oft verknüpft werden können soll [und so lautet ja eine zentrale Anforderung für den PIAV!], so wären in einem konventionellen Datenmodell weitere [(n * (n-1))/2], also 190 verschiedene Linktabellen vorzusehen.

Ein konventionelles Datenmodell, das diese wesentliche Anforderung der Fachlichkeit erfüllt, umfasst also (mindestens) 20 Objektetabellen, darin mindestens 400 Spalten und 190 Linktabellen. Wenn Ihr Fallbearbeitungssystem wesentlich weniger Tabellen aufweist und keine zentrale Linktabelle verwendet, ist das kein Zeichen für seine besondere „Qualität“, sondern beweist nur, dass nicht alle Verknüpfungen zwischen Objekten darin gespeichert werden können. Informationsverluste, wie sie im NSU-Fall offensichtlich geschehen sind, sind damit unausweichlich.

Die Struktur des generischen Datenmodells

Das generische Datenmodell ist vollkommen unabhängig vom Informationsmodell. Es handelt sich um eine immer gleiche, abstrakte Tabellenstruktur, die Informationen aufnehmen kann, die

  • beliebige Objekttypen umfasst,
  • zu jedem Objekttypen beliebige Merkmalstypen enthalten kann und
  • beliebige Objekte über eine zentrale Linktabelle mit beliebigen anderen Objekten verknüpfen kann.

Zentrale Tabelle für alle Objekte

In diesem Datenmodell gibt es nicht viele verschiedene Objektetabellen für die verschiedenen Objekttypen. Vielmehr gibt es nur eine einzige Tabelle für sämtliche Objekte und in dieser Tabelle wird für jedes Objekt nur ein Name/Bezeichner gespeichert, sowie eine Kennzeichnung für den Objekttyp. So kann man alle Adressen oder Personen der Firmen oder sonstigen Objekte aus dieser Tabelle filtern, indem man den gewünschten Objekttyp angibt.
Insbesondere stehen in der zentralen Objektetabelle auch weder Merkmale, noch „Fremdschlüssel“ für die Verknüpfung mit anderen Objekten.

Zentrale Tabelle für alle Merkmale

Natürlich gibt es auch im generischen Datenmodell Merkmale, also Einzelheiten, mit denen man Objekte näher identifiziert (wie z.B. mit Namensangaben) oder beschreibt. Merkmale bestehen grundsätzlich immer – wir hatten dies bereits im Teil 3 dieser Serie beleuchtet – aus einem Pärchen aus Merkmalsbedeutung („Familienname“) und Merkmalsbegriff („Schuster“ / „Uhlmann“ / „Djokovic“ / … Im generischen Datenmodell werden diese Pärchen auch ausdrücklich so gebildet und gespeichert. Es gibt also eine zentrale Merkmalstabelle, in der für jedes benutzte Merkmal ein Pärchen eingetragen ist, das aus der Merkmalsbedeutung (oder einem Kennzeichner dafür) besteht und einem damit verbundenen Merkmalsbegriff – und zwar unabhängig davon, auf welches Objekt sich das entsprechende Merkmal bezieht.

Verknüpfung von Objekten und Merkmalen

Um nun ein Objekt mit „seinen“ Merkmalen zu verknüpfen, gibt es bei der generischen Modellierung ideale und weniger ideale Verfahren, die im Ergebnis jedoch auf das Gleiche hinauslaufen: Es wird nämlich eine Verknüpfung erstellt zwischen dem jeweiligen Objekt und dem Merkmal, das zum entsprechenden Objekt gehört.

Diese Vorgehensweise hat Vorteile gegenüber der konventionellen Modellierung gerade für polizeiliche Fallbearbeitungssysteme. Denn anders, als im Einwohnermelderegister oder Telefonverzeichnis, wo immer die gleichen Grundinformationen / Merkmale zu einer Person / einem Telefoneintrag vorliegen, sind objektbezogene Informationen in der polizeilichen Fallbearbeitung i.d.R. sowohl sehr unterschiedlich, als auch sehr lückenhaft. Beim Einsatz der generischen Modellierung kann man zu jedem Objekt nach und nach sämtliche Merkmale hinzufügen, so, wie sie bekannt werden.

Bei konventioneller Modellierung muss man dagegen für jedes Objekt einen „Datensatz“ anlegen, selbst wenn über das Objekt zu diesem Zeitpunkt rein gar nichts bekannt ist („unbekannter Täter“). Besonders nachteilig wird es bei konventioneller Modellierung, wenn das System es gar nicht zulässt, dass Objekte angelegt werden, für die (noch) keine Merkmale bekannt sind. In diesem Fall fällt der „unbekannte Täter“ unter den Tisch und damit alle sonstigen Informationen, die dazu durchaus schon vorhanden sind (siehe das Beispiel mit den Radfahrern im Fall der NSU-Ermittlungen).

Zentrale Linktabelle für alle Verknüpfungen von Objekten

Und dann gibt es bei der generischen Modellierung noch eine „allumfassende“ Lösung für sämtliche Verknüpfungen zwischen Objekten: Es gibt da nämlich eine zentrale Linktabelle. Sie kann verwendet werden, um Verknüpfungen aller Kardinalitäten abzubilden, also 1:1, bzw. 1:n- bzw. m:n-Verknüpfungen oder – anders ausgedrückt – um jedes Objekt mit jedem anderen Objekt so oft, wie eben nötig, verknüpfen zu können. Für jede einzelne Verknüpfung zwischen zwei Objekten wird in die zentrale Linktabelle ein Datensatz geschrieben. Er enthält den „Fremdschlüssel“ = Verweis auf das erste Objekt und auf das zweite (damit verknüpfte) Objekt in der zentralen Objektetabelle, ferner für jedes der beiden Objekte den jeweiligen Objekttyp(kennzeichner), sowie üblicher Weise eine Aussage über die Beziehung.

Wie kommt das Informationsmodell ins generische Datenmodell?

Es bleibt natürlich – für die generische Modellierung – die wesentliche Frage danach, wo und wie das Informationsmodell bei der generischen Modellierung berücksichtigt wird. Die Antwort dafür nach den bisherigen Ausführungen eigentlich schon auf der Hand:

Vorratsliste / „Repository“ für Objekttypen

Jedes Objekt in der zentralen Tabelle der Objekte erhält, wie wir oben gesehen hatten, einen Objekttyp. Der Vorrat der notwendigen bzw. zulässigen Objekttypen ist ja Teil der Definitionen des Informationsmodells. Dieser Vorrat an Objekttypen wird im generischen Modell in einer Vorratsliste (engl.: Repository) für Objekttypen gespeichert. Jedesmal, wenn ein neues Objekt in einem generischen Modell angelegt wird, wählt der Anwender den gewünschten Objekttyp aus dieser Vorratsliste aus.

Vorratsliste für Merkmalstypen

Genauso verhält es sich mit den Merkmalstypen. Das Informationsmodell liefert für jeden Objekttyp eine Liste der Merkmalstypen, die notwendig sind, um Merkmale für Objekte des gewünschten Typs zu speichern. Dieser Vorrat an Merkmalstypen (für jeden Objekttyp) wird im generischen Modell in einer weiteren Vorratsliste (engl. Repository) der Merkmalstypen gespeichert; wenn ein neues Merkmal zu dem gerade bearbeiteten Objekt angelegt wird, wählt der Anwender den gewünschten Merkmalstyp (z.B. „Familienname“ für eine Person, „Kfz-Kennzeichen“ für ein Fahrzeug o.ä.) aus der Vorratsliste aus und tippt dazu den richtigen Merkmalsbegriff (Müller, Meier, Schröder für den Familiennamen usw. ) ein oder wählt den Merkmalsbegriff (z.B. für den Merkmalstyp „Familienstand“) aus einer vorbereiteten Vorratsliste für Merkmalsbegriffe (zu einzelnen Merkmalstypen) aus. Dort würde dann für den Merkmalstyp „Familienstand“ angeboten: „ledig“, | „verheiratet“ | „verwitwet“ | „geschieden“ | …

Und wo finden sich die Kataloge?!

Und damit auch solche Kataloge, d.h. Listen für Merkmalsbegriffe, vorgehalten werden können, gibt es im generischen Datenmodell noch eine Vorratsliste (ein Repository) für alle diese Merkmalsbegriffe.

Wann empfiehlt sich welches Modellierungsverfahren?

Doch wann empfiehlt sich nun welches Modellierungsverfahren? Um diese Frage zu beantworten, müssen nicht nur – wie bisher – die fachlichen Anforderungen auf den Tisch, sondern zusätzlich auch systemische und technische. Teil 7 aus dieser Reihe wird sich mit diesem Thema eingehend beschäftigen.

___________________________________________________________________________________________________

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