Dr. Dieter Mainz, Berater für Systementwicklung in der Kölner IBM-Niederlassung.
Für den Anwender zählte was er kaufen kann. Auf diesen Standpunkt stellt sich Dieter Mainz (siehe auch vorstehende Diskussion auf Seite 31), wenn er die relationalen Datenbanken gegen das Entity-Relationship-Modell verteidigt. Schließlich, so argumentiert er, sei es schwierig genug, die Daten von den Anwendungen zu befreien. Alles andere sei Zukunftsmusik.
Der Bedarf an Informationen im Unternehmen führt aus sehr unterschiedlichen Blickwinkeln zu einer Mannigfaltigkeit an Datenzusammenstellungen, die allein durch die große Zahl bedingt, nicht mehr präventiv spezifizierbar sind. Es ist ein Unterschied, ob man sich am Kunden, am Produkt oder an der Suche nach freien Marktsegmenten orientiert.
Zu den Kernfragen für den Aufbau von Informationssystemen gehört die Strukturierung der Daten. Hier müssen alle Informationsbedürfnisse auf möglichst einfache Weise so festgelegt werden, daß auch vorher nicht absehbare Fragen beantwortet werden können. Eine solche Struktur kann nicht das Abbild bestimmter Anwendungen oder Ausgabelisten sein.
Zwei mächtige Darstellungsmethoden
Zur Verwirklichung einer solchen Datenstrukturierung stehen zwei mächtige Darstellungsmethoden zur Verfügung: die Sprache des Entity-Relationship- und die des Relationenmodells. Beide dienen der Analyse, der Dokumentation, der Speicherung und Benutzung der Daten und deren strukturellen Beziehungen. In der Praxis der Datenmodellierung hat sich gezeigt, daß man sich in einer guten Position befindet, wenn man beide Sprachebenen benutzt.
Beim Entity-Relationship-Modell werden - das ergibt sich aus der Logik der Daten - Datenelemente als Attribute Informationseinheiten zugeordnet. Diese heißen Entitäten (Entities) und stehen in Beziehungen (Relationships) zueinander.
Im Relationenmodell werden diese zwei Basiseinheiten der Datenwelt - Entität und Beziehung - in einer einheitlichen Form dargestellt: in der mathematischen Struktur einer Relation, auch Tabelle genannt. Die Tabellenstruktur definiert den Informationsbedarf eines Unternehmens, die Tabelleninhalte liefern die Information.
Jede Operation im Relationenmodell, ob Selektion, Projektion oder Join, arbeitet im Raum der Relationen (Relationenalgebra). Ein- und Ausgaben
sind Relationen, auf der Ebene der Unternehmensdaten wie auf der Ebene beschreibender Daten (Metadaten). Für eine strenge Definition eines relationalen Datenbank-Managment-Systems wird auf die von E. F. Codd 1985 aufgestellten zwölf Regeln verwiesen.
Die Stärke des Entity-Relaltionship-Modells liegt in sein , er Anschaulichkeit und in der Betonung der Semantik der Daten. Relationen glänzen durch formale, mathematische Präzision und nicht zuletzt durch die Verfügbarkeit relationaler Datenbank-Management-Systeme.
Dabei eröffnet bei schwierigen Entscheidungsprozessen für die bestmöglichen Strukturen eines Unternehmensdaten-Modells die Transformation der einen in die andere Sprachebene zusätzliche Lösungswege.
Die grundlegenden Strukturen lassen sich in beiden Modellen auf eine Eins-zu-eins-Korrespondenz bringen. Die im Entity-Relationship-Modell liegende Semantik wird durch eine disziplinierte Definition und Bezeichnung der Relationenattribute mit den Begriffen "Domäne", "Schlüssel" und "Rolle" in das Relationensystem überführt. Man erhält dabei zwangsläufig Relationen in der 3. oder in der 5. Normalform.
Heute verlangen die Anwender nach einem unmittelbaren Zugriff auf die Daten mit nichtprozeduralen Sprachen, wollen logisch kombinierbare Daten in der Gesamtheit ihres Varianzspektrums auch DV-technisch kombinierbar machen und fragen zudem nach mengenorientierter, verteilter, kooperativer Datenverarbeitung: Forderungen dieser Art werden die Informationsverarbeitung der 90er Jahre bestimmen. Erfüllen können sie nur relationale Datenbanksysteme.
Auf der Basis des Relationenmodells wird mit dem Ziel weiterentwickelt, komplexe Objekte für die Integration von technisch-wissenschaftlichen, administrativen und Büroanwendungen einzubeziehen. Nicht-skalare Tabellenwerte sollen zugelassen werden.
Das ist die Perpektive, aus der sich heute die Frage nach der Abgrenzung von Datenbanksystemen und dem System der Funktionen und Geschäftsabläufe neu stellt.