6.1 Beziehungsfindung

Am Anfang der Modellierung steht immer die Festlegung von Entitäten und Beziehungen, die dann im weiteren zu Typen zusammengefasst werden. Entitäten können damit noch relativ leicht erkannt werden. Entweder direkt (weil offensichtlich) oder durch Attribute, deren Erfassung als Ziel der Modellierung vorgegeben wird oder die für die gewünschten Anwendungen nötig sind. Schwieriger ist es mit Beziehungen. Einige Beispiele:

• Liefert in einer Datenbank mit Produkten und Kunden
• bietet_an in einer Datenbank zu Datenbanksystemen oder Online-Datenbanken
• leitet_Abteilung und arbeitet_in in einer Datenbank zu den Mitarbeitern eines Unternehmens

Die Beispiele machen deutlich: Beziehungen in Datenbanken setzen Entitäten verschiedener Entitätstypen miteinander in Beziehung. Manchmal auch nur die eines Entitätstyps, z.B. in leitet_Abteilung oder die mehrerer, z.B. in dem in der Literatur vielzitierten Beispiel einer Datenbank zu Projekten, Teilen und Lieferanten, wenn festgehalten werden soll, welches Teil von welchem Lieferanten in welches Projekt geliefert wird. Hierbei entsteht eine dreistellige Beziehung zwischen den Entitätstypen.

Dieses „in Beziehung setzen“ kann natürlich auch auf einem realen Vorgang beruhen, wie in dem oben angeführten Beispiel liefert.

Oftmals ist es aber nicht einfach zu entscheiden, was Entität und was Beziehung ist und schon kleine Änderungen der Semantik können das Datenmodell ändern. Dies soll an einem Beispiel veranschaulicht werden.

6.2 Beispiel Transporte

Nehmen wir als Beispiel Transportvorgänge in einem Transportunternehmen. Stehen die Transporte im Vordergrund, könnte es in sehr einfacher Form (vielleicht für einen Fahrradkurier) wie in der folgenden Abbildung (Lösung 1) modelliert werden. Für jeden Transport werden Absender- und Empfängername, Zeitpunkt des Transports und weitere Attribute erhoben, die den Transportvorgang selbst beschreiben. Außerdem werden die Transporte durchnummeriert, was einen problemlosen Schlüssel liefert.

Variante 1

Für den nächsten Schritt nehmen wir an, dass Absender und Empfänger detaillierter beschrieben werden sollen und dass sie auch unterschiedliche Attribute haben, z.B. weil die einen hauptsächlich Unternehmen und die anderen Privatleute sind. Dann wäre eine Modellierung wie in der nächsten Abbildung denkbar.

Variante 2

Es entstehen zwei verschiedene Entitätstypen (mit Schlüsseln, die den Absender oder Empfänger identifizieren: IdAbs und IdEmpf) und der Transportvorgang wird durch einen Beziehungstyp erfasst.

Eine weitere Variante zeigt die folgende Abbildung. Sie ist sinnvoll, wenn Absender und Empfänger durch dieselben Attribute beschrieben werden, d.h., wenn sie (datenbanktechnisch) „gleich“ sind. Dann müssen sie zu einem einzigen Entitätstyp Kunden zusammengefasst werden auf dem sich eine rekursive Beziehung Transporte befindet.

Variante 3

Zu lösen bleibt hier noch das Problem der Identifizierung einzelner Transporte. Entweder durch Zusammenfassen der Informationen zu Absender, Empfänger und Zeitpunkt oder durch Einführung eines Attributs IdTransport.

Sind sich die Kunden bezüglich ihrer Attribute weitgehend aber nicht vollständig gleich, könnte auch eine Generalisierung/Spezialisierung eingeführt werden. Dies zeigt die folgende Abbildung. Hier wurde angenommen, dass sich die Kunden sinnvoll in private und gewerbliche Kunden unterteilen lassen. In letzteren können dann noch die Großkunden separiert werden.

Variante 4

Mit obigen Beispielen sollte deutlich geworden sein, dass gerade bei Beziehungen kleine Änderungen in der Semantik zu großen Änderungen des Datenmodells führen können.