Semantische Datenmodellierung Teil 1: Grundlagen. Hans-Georg Hopf

Transkript

1 Semantische Datenmodellierung Teil 1: Grundlagen Hans-Georg Hopf 25. März 2004

2 Inhaltsverzeichnis 1 Dem Informationsnotstand begegnen 2 2 Datenmodelle Datenablage Klassifikation Relationenmodell Relation Integritätsbedingungen Beispiel Übungen Was Sie nach der Bearbeitung dieses Teils kennen und können sollten: Sie erfahren, welche Probleme mit dem Ablegen von Daten auftreten können. Sie erfahren, welche Aufgabe Datenmodelle haben und wie sie grob klassifiziert werden können. Ein einfaches tabellenorientiertes Datenmodell (Relationenmodell) wird vorgestellt. Sie sollten an einem Beispiel ein Relationenmodell entwickeln. 1

3 Kapitel 1 Dem Informationsnotstand begegnen Information ist Macht! Wir leben in einer Informationsgesellschaft. Beliebig viele Informationen sind verfügbar, werden benötigt und werden transportiert, verarbeitet und gespeichert. Oft gibt es kein klares Konzept für den Umgang mit Information. Auf welche Information kann in Zukunft verzichtet werden? Welche Information muß aufbewahrt, muß gespeichert werden? Immer wieder stellt man fest, daß ein erst neulich weggeworfener Bericht gerade jetzt nützliche Dienste leisten könnte. Auf der anderen Seite türmen sich im Archiv Akten, die seit Jahren niemand mehr benötigt. Die Festplatte läuft über, aber man weiß nicht, was von den unzähligen Dateien noch relevante Information enthält und was nicht. Das Durchforsten der Dateien wird immer wieder hinausgeschoben und unterbleibt häufig ganz. Zur Ablage werden Informationen klassifiziert und eingeordnet, um im Bedarfsfall möglichst schnell wiedergefunden zu werden. Wem ist es aber nicht schon passiert, daß abgelegte Unterlagen nicht gefunden wurden, man erst später per Zufall feststellt, daß sie anders klassifiziert wurden als gedacht und folgerichtig an anderer Stelle aufbewahrt werden. Abhilfe verspricht man sich häufig durch den Einsatz einer Datenbank. Und doch erlebt man trotz datenbankgestützter Ablage immer wieder Überraschungen. Ein Unternehmen möchte sämtliche relevanten Informationen über seine EDV- Lieferanten in einer Datenbank ablegen. Man entschließt sich, eine Tabelle mit mehreren Spalten anzulegen. Ein Lieferant wird mit Namen aufgeführt (Spalte LName). Jeder Lieferant hat zusätzlich eine Kurzbezeichnung LNummer. Der Firmensitz des Lieferanten wird in der Spalte Stadt angegeben. Seine Zuverlässigkeit und Liefertreue wird über einen Bewertungsfaktor berücksichtigt; dieser Bewertungsfaktor ist in der Spalte Status hinterlegt. Die von einem Lieferanten im laufenden Kalenderjahr aktuell gelieferten Produkte finden sich in der Spalte Produkt, die gelieferten Stückzahlen werden in der Spalte Menge aufgeführt. Eine Zeile der Tabelle kann eindeutig identifiziert werden durch Angabe der Lieferantennummer LNummer und des gelieferten 2

4 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Produkts. Ein Beispiel für diese Lieferantendatenbank ist in der Tabelle 1.1 zusammengestellt. Lieferanteninformation LNummer LName Status Stadt Produkt Menge 1 Schmidt 20 Erlangen PC 20 1 Schmidt 20 Erlangen Drucker 6 1 Schmidt 20 Erlangen Scanner 4 1 Schmidt 20 Erlangen Tastatur 20 1 Schmidt 20 Erlangen Bildschirm 20 1 Schmidt 20 Erlangen Kartenleser 1 2 Müller 10 Nürnberg PC 5 2 Müller 10 Nürnberg Drucker 1 3 Meier 10 Nürnberg Drucker 2 4 Beck 20 Berlin Drucker 2 4 Beck 20 Berlin Tastatur 5 4 Beck 20 Berlin Bildschirm 5 Tabelle 1.1: Lieferantendatenbank: erste Version Übliche Operationen auf Tabellen sind: Einfügen Löschen Aktualisieren Mit allen Operationen gibt es mit der angegebenen Lieferantentabelle Probleme: Einfügen: Ist von einem Lieferanten nur z.b. der Firmensitz und der Status bekannt, nicht aber das Produkt, das er anbietet, dann kann diese Information nicht in die Tabelle aufgenommen werden, da zur eindeutigen Identifikation die Angabe der Lieferantennummer und des Produkts notwendig ist. Beispiel: Ein neuer Lieferant Huber aus München kann nicht in die Tabelle eingetragen werden, solange nicht bekannt ist, welches Produkt er anbietet. Das Problem: Informationen können erst in die Tabelle eingetragen werden, wenn alle Schlüsselattribute definiert sind. Löschen: Ist ein Lieferant nur mit einer Zeile in der Tabelle vertreten, und soll das von ihm angebotene Produkt aus dem Sortiment unseres Unternehmens gestrichen werden, dann verliert man auch alle weiteren Angaben über den Liefereanten. Beispiel: Der Lieferant mit der Lieferantennummer 3 scheidet als Lieferant des Produktes Drucker aus. Diese Datenänderung bedingt das Version 1.0 / 25. März c H.-G. Hopf

5 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Löschen des entsprechenden Tabelleneintrags. Da weitere Zeilen mit dem Lieferanten nicht in der Tabelle vertreten sind, ist alle Information über den Lieferanten mit dieser Löschoperation verloren gegangen. Das Problem: Bei Löschoperationen werden mehr Informationen als nötig gelöscht. Aktualisieren: Der Firmensitz einzelner Lieferanten taucht in der Tabelle mehrfach auf. Dieser Umstand erschwert konsistente Änderungen. Beispiel: In der Beispieltabelle ist der Lieferant 1 mit Firmensitz in Erlangen sechsmal vertreten. Bei einer Verlagerung des Firmensitzes von Erlangen nach München müssen alle sechs Einträge verändert werden. Dabei ergibt sich leicht die Gefahr inkonsistenter Daten. Das Problem: Redundante Daten erschweren konsistente Datenänderungen. Die genannten Probleme sind typisch. Man bezeichnet sie als Anomalie 1. Mit Anomalien sind in diesem Zusammenhang Unregelmäßigkeiten im operationellen Umgang mit Tabellen gemeint: Man spricht von Einfüge-Anomalie (Insert-Anomalie), Lösch-Anomalie (Delete- Anomalie) oder Aktualisierungs- Anomalie (Update-Anomalie). Das Auftreten dieser Anomalien ist ein untrüglicher Indikator für das Vorliegen von strukturellen Defiziten in der Tabelle bzw. in der Datenstruktur. Der Grund dafür liegt darin, daß gleiche Information mehrfach auftritt, also Information redundant ist. Eine Zerlegung der Tabelle in mehrere Einzeltabellen schafft schnell Abhilfe. Eine neue Daternstruktur, bestehend aus den zwei Tabellen Lieferant und Lieferung (siehe Tabelle 1.2) weist die oben aufgeführten Defizite im operationellen Umgang nicht mehr auf. Einfügen: Der neue Lieferant Huber aus München kann ohne Schwierigkeiten in die Tabelle Lieferant eingetragen werden, ohne daß bekannt ist, welches Produkt er anbietet. Löschen: Der Lieferant mit der Lieferantennummer 3 scheidet als Lieferant des Produktes Drucker aus. Der entsprechende Datensatz in der Tabelle Lieferung wird gelöscht. Alle anderen Daten über den Lieferanten sind in der Tabelle Lieferant weiter verfügbar. Aktualisieren: Die Verlagerung des Firmensitzes für den Lieferanten 1 von Erlangen nach München erfordert die Änderung eines einzigen Eintrags in der Tabelle Lieferant. Inkonsistente Daten können nicht auftreten. Aber, wie kommt man auf eine angemessene Zerlegung, auf eine angemessene Datenstruktur? Daß eine willkürliche Zerlegung größte Gefahren in sich birgt, zeigt das folgende Beispiel. 1 Anomalie bedeutet: Zustand des Anomalen, Regelwidrigkeit, Unregelmäßigkeit. Version 1.0 / 25. März c H.-G. Hopf

6 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Lieferant LNummer LName Status Stadt 1 Schmidt 20 Erlangen 2 Müller 10 Nürnberg 3 Meier 10 Nürnberg 4 Beck 20 Berlin Lieferung LNummer Produkt Menge 1 PC 20 1 Drucker 6 1 Scanner 4 1 Tastatur 20 1 Bildschirm 20 1 Kartenleser 1 2 PC 5 2 Drucker 1 3 Drucker 2 4 Drucker 2 4 Tastatur 5 4 Bildschirm 5 Tabelle 1.2: Lieferantendatenbank: zweite Version So ging im Frühjahr 1996 durch die Presse: Professor Dank Telekom 2 und Telekom schmückt Adressaten: Zum Dr. gekürt - Schuld war ein Softwarefehler 3 (siehe Abbildung 1.1). Was war passiert? Einige Tausend Telekom- Kunden bekamen bei der Einführung eines neuen Informationsdienstes Post. Dabei waren die Adressaten irrtümlich teils mit Dr. teils mit Prof. geschmückt. Ein Telekomvertreter erklärte die Panne mit einem Softwarefehler in Adressendateien (siehe Pressenotiz). Was kann sich hinter einem derartigen Softwarefehler verbergen? Das folgende kleine, bewußt einfach gehaltene und auf das Notwendigste reduzierte Beispiel (siehe Tabelle 1.3 und 1.4) soll zeigen, wie ein derartiger Fehler zustande kommen kann. Wir gehen von einer Adressen-Tabelle mit den Attributen Name, Titel und Stadt aus. Diese Tabelle soll in zwei Einzeltabellen aufgespalten werden. Die Zerlegungsprodukte sind zum einen eine Tabelle mit den Attributen Name und Titel, zum andern eine Tabelle mit den Attributen Name und Stadt. Beide Tabellen ergeben sich als Projektion der Ausgangstabelle auf die entsprechenden Attribute. Diese Zerlegung ist in diesem konstruierten Fall natürlich nicht besonders sinnvoll. Bei realistischen, umfangreichen Tabellen mit großen Attributlisten ist eine Zerlegung aber ein häufig gewähltes Verfahren um die Übersicht zu behalten. Die Ausgangsinformation kann durch eine Verbund- Operation (Join über das Attribut Name) leicht zurückgewonnen werden (sie- 2 Süddeutsche Zeitung, Erlanger Nachrichten, Version 1.0 / 25. März c H.-G. Hopf

7 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Abbildung 1.1: Presseveröffentlichungen über einen Softwarefehler he Tabelle 1.3). Die Tabelle 1.4 zeigt die Ausgangstabelle nochmals, jedoch wurde eine kleine Modifikation vorgenommen: Herr Dr. Schmidt zieht von Erlangen nach Nürnberg um. Das Zerlegungsverfahren wird wie oben dargestellt beibehalten. Die Rekonstruktion zeigt jedoch in diesem Fall, daß neben den Datensätzen der Ausgangstabelle weitere sogenannte spuriose Datensätze in der Verbund- Operation entstehen. Als Nebeneffekt ergibt sich, daß vorher nicht promovierte Personen (z.b. Herr Schmidt aus Erlangen) zu akademischen Weihen gekommen sind. Im Fachjargon spricht man von einer Zerlegung mit Informationsverlust. Auf diese Weise kann es zu oben beschriebenen Vorkommnisssen aus dem Frühjahr 1996 kommen. Der Softwarefehler stellt sich als Unzulänglichkeit in der Struktur des Datenbestandes heraus. Probleme dieser Art sind nicht selten. Schlecht strukturierte oder sogar unstrukturierte Datenablage kommt immer wieder vor, häufiger als man denkt! Wie oft werden Tabellen um einige weitere allgemein gehaltene Attribute ergänzt, die derzeit noch nicht benötigt werden, aber zukünftig vermeintlich Version 1.0 / 25. März c H.-G. Hopf

8 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Name Titel Stadt Schmidt Erlangen Schmidt Dr. Erlangen Maier Prof. Nürnberg Zerlegung: Name Schmidt Schmidt Maier Titel Dr. Prof. Name Schmidt Maier Stadt Erlangen Nürnberg Rekonstruktion: Name Titel Stadt Schmidt Erlangen Schmidt Dr. Erlangen Maier Prof. Nürnberg Tabelle 1.3: Adressen-Tabelle: erstes Szenario Name Titel Stadt Schmidt Erlangen Schmidt Dr. Nürnberg Maier Prof. Nürnberg Zerlegung: Name Schmidt Schmidt Maier Titel Dr. Prof. Name Schmidt Schmidt Maier Stadt Erlangen Nürnberg Nürnberg Rekonstruktion: Name Titel Stadt Schmidt Erlangen Schmidt Nürnberg Schmidt Dr. Erlangen Schmidt Dr. Nürnberg Maier Prof. Nürnberg Tabelle 1.4: Adressen-Tabelle: zweites Szenario Version 1.0 / 25. März c H.-G. Hopf

9 KAPITEL 1. DEM INFORMATIONSNOTSTAND BEGEGNEN Flexibilität in die Datenbank bringen sollen. Wie oft findet man in Datenbanktabellen Spalten, wo niemand mehr weiß, wozu diese Werte gedacht waren, wo unbekannt ist, von welchen Tools eventuell auf diese Spaltenelemente zugegriffen wird. Man löscht die Spalten trotzdem oder gerade deswegen bei einer Überarbeitung nicht. Tabellen werden zu groß und zu unübersichtlich. Die abgelegte Datenmenge wächst beständig an, die Übersicht geht verloren. Oft sind zudem Daten über die ganze Firma (planlos) verteilt, teilweise als unabhängige Dateninseln teilweise zwar vernetzt aber trotzdem zu einem hohen Prozentsatz redundant. Man könnte auf die Idee kommen, von einem Informationsnotstand zu sprechen. Wie kann man diesem Informationsnotstand begegnen? Drei Lösungswege bieten sich an: 1. Die intuitive Vorgehensweise: Mit gesundem Menschenverstand ausgerüstet zerlegt man zu große Informationseinheiten und prägt ihnen eine vernünftige Struktur auf. Wie wir gesehen haben, ist diese intuitive Vorgehensweise im Ergebnis nicht sonderlich zuverlässig. 2. Die Normalisierung: Das Verfahren der Normalisierung ist sicher geeignet, eine Datenstruktur mit dem benötigten Grad an Redundanzfreiheit zu erzeugen. Doch dieses vergleichsweise mathematische Verfahren ist insbesondere bei umfangreichen Datenstrukturen aufwendig und sehr mühsam. 3. Bleibt die Datenmodellierung: Hier werden Datenmodellierungssprachen zum Spezifikationszeitpunkt benutzt, um großen Datenbeständen eine möglichst redundanzfreie, praxisgerechte, nachvollziehbare und damit zukunftssichere Struktur zu geben. Das erfolgreiche Anwenden dieses Verfahrens erfordert allerdings viel Erfahrung. Wir wollen im folgenden Text an Hand einer Datenmodellierungssprache (Extended Entity-Relationship Modell) prüfen, ob Datenmodellierung eine geeignete Alternative ist, um dem Informationsnotstand zu begegnen. Version 1.0 / 25. März c H.-G. Hopf

10 Kapitel 2 Datenmodelle Ein Datenmodell soll eine Situation oder einen Ausschnitt der realen Welt erfassen und in geeigneter Form zur weiteren, üblicherweise rechnergestützten Nutzung und Verarbeitung verfügbar machen. Dabei sollen wichtige Aspekte der realen Welt Berücksichtigung finden. Unwesentliche Einzelheiten, die im Gesamtzusammenhang keine Bedeutung haben, sollen unberücksichtigt bleiben. Dieses Überprüfen und Filtern von Aspekten der realen Welt in Hinblick auf ihre Bedeutung für das angestrebte Beschreibungsziel nennt man Abstraktion. Ergebnis des Abstraktionsprozesses ist Information über die reale Welt. Information ist dabei definiert als Kenntnis über bestimmte Sachverhalte und Vorgänge in einem Teil der wahrgenommenen Realität (siehe [SCHN 86 ]) oder prägnanter ausgedrückt als zielgerichtetes, zweckorientiertes Wissen (siehe [FLE 89 ]). Abbildung 2.1: Zusammenhang zwischen Information und Daten, Abstraktion und Repräsentation 9

11 2.1. DATENABLAGE KAPITEL 2. DATENMODELLE Im nächsten Schritt muß dieses Wissen für die weitere Verarbeitung aufbereitet werden. Daten dienen zur verarbeitungsgerechten Darstellung (Repräsentation) von Information. Die Daten werden in Datenstrukturen abgelegt. Datenmodelle dienen zur Definition von geeigneten Datenstrukturen. 2.1 Probleme bei der Datenablage Das Ablegen von Information in Datenstrukturen ist mit zwei grundsätzlichen Problemen behaftet: Zunächst stellt sich die Frage nach der Organisation der Information bzw. der aus der Information abgeleiteten Daten. Hier muß entschieden werden, welche Informationselemente bzw. Datenelemente zusammengehören, welche Beziehungen zwischen Informationseinheiten bestehen. Informationssammlung Firma Workstation Ressourcen FIRMA Abbildung 2.2: Informationssammlung zum Thema Firma in Form einer Mind Map Darstellung Als Beispiel betrachten wir eine Firma und in der Firma anfallende Informationen: Version 1.0 / 25. März c H.-G. Hopf

12 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE Von Angestellten der Firma sollten folgende Aspekte bekannt sein: Name, Vorname, Geburtsdatum, Personalnummer, Adresse, Telephonnummer, Ausbildung/Fachgebiet, Funktion, Mitgliedschaft in Berufsverbänden, Beteiligung an Arbeitsgruppen, Mitgliedschaft in Gremien, Mitgliedschaft in einer Gewerkschaft, derzeitiges Arbeitsprofil, Gehalt; Funktionen innerhalb der Firma sind: Manager, Ingenieur, Techniker, Sekretär/Sekretärin, Abteilungsleiter, Hauptabteilungsleiter, Aufsichtsrat, Betriebsrat; Von den Abteilungen/Hauptabteilungen soll abgespeichert werden: Umsatz, benutzte Gebäude, durchgeführte bzw. derzeit bearbeitete Projekte, Ausstattung mit Ressourcen (PC, Workstation,...); Obwohl schon strukturiert aufgelistet, z.b. in der Form eines Mind Maps (siehe Abbildung 2.2), ist dieser Zusammenstellung nicht ohne weiteres eine verwertbare Datenstruktur anzusehen. Bei der Transformation von Information in Daten geht häufig die Bedeutung einzelner Datenelemente verloren. Der Verarbeiter kann damit den Daten nicht mehr entnehmen, welche Operationen auf diesen Daten möglich oder erlaubt sind, er muß wissen, wie er mit den Daten umzugehen hat. Die Bedeutung (Semantik 1 ) der Daten bleibt häufig zu einem hohen Prozentsatz in der Repräsentation unberücksichtigt. Folgende Datenelemente sind als Datensatz in einer Personaldatenbank abgelegt: Helga Meier Schillerstrasse Erlangen Die ersten fünf Datenelemente kann man als Adreßinformation interpretieren. Das sechste Datenelement kann man in Zusammenhang mit der vorstehenden Adreßinformation als Telephonnummer deuten. Diese Interpretation ist jedoch nur eine von vielen möglichen. Genauso gut kann sich dahinter das Körpermaß: der Helga Meier verbergen. 2.2 Klassifikation von Datenmodellen Datenstrukturen unterscheiden sich: im Grad an Speichereffizienz, d.h. im Umfang in dem auf effiziente Ablage der Information geachtet wird. in der Granularität d.h. im Detaillierungsgrad, mit der die Information dargestellt wird; 1 Semantik ist die Lehre von den Beziehungen zwischen Sprache und Wirklichkeit bzw. kognitiven und kulturellen Elementen: siehe [SCHN 86 ] Version 1.0 / 25. März c H.-G. Hopf

13 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE im Grad an Semantik, d.h. in der Fähigkeit Bedeutung der Information darzustellen Die Repräsentation der Information kann gemäß der verschiedenen Sichtweisen auf unterschiedlichen Ebenen erfolgen. Die einzelnen Sichtweisen bzw. Betrachtungsebenen für Information sind 2 : Effizienzorientierte Sichtweise: Diese Sichtweise führt zur Darstellung von physisch gespeicherten Daten (physical data structure). An physische Datenstrukturen wird im allgemeinen die Anforderung gestellt, einen positiven Beitrag zur Steigerung der Effizienz des Systems zu erbringen. Effizienzsteigernde Komponenten physischer Datenstrukturen sind z.b. Zugriffspfade, wie Zeiger oder Indizes, aber auch bestimmte effizienzgünstige Anordnungen der Daten als Datensätze (Speicherstrukturen). Benutzerspezifische Sichtweise: Diese Sichtweise führt zur Darstellung von logischen Datenstrukturen (logical data structure). Logische Datenstrukturen dienen ausschließlich der Darstellung von problemgegebenen Zusammenhängen des darzustellenden Informationsbereichs. Logische Datenstrukturen sind häufig nach Gesichtspunkten konzipiert, die dem Systembenutzer die Arbeit mit diesen Strukturen erleichtern sollen. Insbesondere enthalten logische Datenstrukturen keine effizienzorientierten Komponenten (im oben beschriebenen Sinn). Logische Datenstrukturen werden jedoch immer wieder beeinflußt einerseits durch technische Randbedingungen des zur Implememtierung vorgesehenen Systems und andererseits anwendungsspezifische Randbedingungen. Bedeutungsorientierte Sichtweise: Diese Sichtweise führt zur Darstellung von konzeptionellen Datenstrukturen (conceptional data structure). Konzeptionelle Datenstrukturen dienen ausschließlich der präzisen Definition der Semantik des darzustellenden Informationsbereichs. Auf spezifische benutzerorientierte oder effizienzorientierte Komponenten wird verzichtet. Von einer konzeptionellen Datenstruktur lassen sich verschiedene, untereinander semantisch äquivalente logische oder physische Datenstrukturen ableiten. Die Komponenten von konzeptionellen Datenstrukturen sind Objekte, elementare Beziehungen und semantische Regeln. Eine Datenstrukturdefinition, d.h. die Definition der für einen Informationsbereich zugelassenen Datenstrukturen, nennt man Datenschema. Ein Datenschema wird in einer Datendefinitionssprache formuliert. Eine häufig eingesetzte Datendefinitionssprache ist beispielsweise die Datendefinitionssprache von SQL (SQL/DDL - SQL data definition language), mit der Tabellen definiert werden können. 2 Diese Definitionen sind weitgehend [SCHN 86 ] entnommen. Version 1.0 / 25. März c H.-G. Hopf

14 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE Sichtweise Schema Datenmodell physisches Schema effizienzorientierte internes Schema Sichtweise benutzerorientierte Sichtweise bedeutungsorientierte Sichtweise logisches Schema externes Schema logisches Schema externes Schema logisches Datenmodell semantisches Datenmodell Tabelle 2.1: Zuordnung: Sichtweise - Datenschema - Datenmodell Informationssysteme / Datenbanksysteme haben üblicherweise eine sogenannte 3-Schema-Architektur bestehend aus den Schemata: internes Schema, logisches Schema und externes Schema. Internes Schema: Das interne Schema definiert implementierungsabhängige Datenstrukturen. Logisches Schema: Das logische Schema stellt die logische Gesamtstruktur dar. Manchmal spricht man hier auch vom konzeptionellen Schema. Externes Schema: Das externe Schema beschreibt die logische Datenstruktur aus der (eingeschränkten) Sicht einer (von eventuell mehreren) Anwendungen. Entsprechend der verschiedenen Sichtweisen (benutzerorientiert, effizienzorientiert, bedeutungsorientiert) kommen unterschiedliche Schemata zur Anwendung. Datenmodelle dienen dazu diese Schemata abzuleiten bzw. darzustellen. Datenmodelle können klassifiziert werden. Diese Klassifikation ist in Abbildung 2.3 dargestellt. Zunächst lassen sich zwei Gruppen unterscheiden: Logische (tabellenorientierte) Datenmodelle (storage models) sollen helfen Information aus einem wohldefinierten, abgegrenzten Informationsbereich strukturiert, transparent und überschaubar darzustellen (siehe [SCHN 86 ]). Mit semantischen Datenmodellen (semantic data models) soll nun sowohl die Organisation von Daten in geeigneten Datenstrukturen (logisches Datenmodell) als auch die möglichst weitgehende Erfassung der Bedeutung von Daten erreicht werden. Innerhalb der semantischen Datenmodelle können wiederum zwei Klassen unterschieden werden: Entity-Attribut-Relations (EAR) Modelle und Objekt- Relations (OR) Modelle (siehe [KIM 95 ]). Version 1.0 / 25. März c H.-G. Hopf

15 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE Abbildung 2.3: Übersicht: Klassifizierung von Datenmodellen Die Abbildung 2.5 soll zusammenfassend die Zusammenhänge zwischen Sichtweisen bzw. Betrachtungsebenen von Information, Datenschemata von Informationssystemen und Datenmodellenklassen darstellen und in ihrer Bedeutung gegeneinander abgrenzen. Die 3-Schema-Architektur gibt eine Grundstruktur vor. Die effizienzorientierte Sichtweise ist sinnvollerweise dem internen Schema zugeordnet. Sowohl logisches als auch externes Schema können durch eine benutzerorientierte Sichtweise aber auch durch eine bedeutungsorientierte Sichtweise bestimmt sein. Im einen Fall kommt ein logisches Datenmodell, z.b. das Relationenmodell, im anderen Fall ein semantisches Datenmodell, z.b. das Extended Entity-Relationship Modell, zur Datenstrukturdefinition zum Einsatz. Im folgenden soll zunächst das Relationenmodell als eine etablierte, weit verbreitete und grundlegende Darstellungmethode im Bereich der logischen Datenmodelle (logische Ebene) vorgestellt werden. Auf Grund einer Analyse der Beschränkungen des Relationenmodells wird dann das Extended Entity- Relationship-Modell als sehr brauchbares semantisches Datenmodell (konzeptionelle Ebene) ausgeführt. Version 1.0 / 25. März c H.-G. Hopf

16 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE Abbildung 2.4: Semantisches Datenmodell Version 1.0 / 25. März c H.-G. Hopf

17 2.2. KLASSIFIKATION KAPITEL 2. DATENMODELLE Abbildung 2.5: Zusammenhang von Sichtweisen/Betrachtungsebenen von Information, Datenschemata von Informationssystemen und Datenmodellen Version 1.0 / 25. März c H.-G. Hopf

18 Kapitel 3 Relationenmodell Der Informations-Container im Relationenmodell ist die Relation. Im ersten Abschnitt soll deshalb dieser aus der Mathematik stammende Begriff Relation erläutert werden. Auskunft über Bedeutung von Informationselementen im Relationenmodell erhält man häufig über Integritätsregeln. Der zweite Abschnitt erläutert zwei grundlegende Integritätskonzepte. Das Kapitel schließt mit einem Beispiel für ein Relationenmodell. 3.1 Relation Die Basis für die Datenmodellierung ist das Objekt. Objekte können identifiziert und näher beschrieben werden. Diese Identifikation und Beschreibung von Objekten geschieht durch Attribute. Rein mathematisch betrachtet kann man ein Attribut (attribute) als Abbildung von einer Menge von Objekten in einen Wertebereich (domain) betrachten. Jedem Objekt dieser Objektmenge wird in dieser durch das betrachtete Attribut vermittelten Abbildung ein Attributwert zugewiesen. Man sagt auch, daß ein derartiges Attribut nur atomare Attributwerte besitzt. Angestellte einer Firma werden durch die Attribute Personalnummer, Vorname, Nachname, Abteilungsbezeichnung beschrieben. Personalnummer kann aufgefaßt werden als Abbildung der Objekte von Angestellter in den Wertebereich [101,.., 120]. Herr Meier bekommt gemäß dieser Abbildung die Personalnummer 101, Herr Müller die Personalnummer 102 und Herr Adam die Personalnummer 103. Auf Grund des gewählten Wertebereichs [101,.., 120] wird deutlich, daß diese Firma keinen Personalausbau über die 20 Personengrenze hinaus plant. Auch dies ist eine wichtige und festzuhaltende Information. Völlig analog kann jetzt mit dem Attribut Vornamen verfahren werden. Vornamen ist eine Abbildung der Objekte von Angestellter in den Wertebereich aller bis zu 30 Zeichen langen Zeichenketten. Herr Meier bekommt auf Grund dieser Abbildung den Vornamen Fritz, Herr Müller den Vornamen Hans und Herr Adam den Vornamen Uli zugewiesen. 17

19 3.1. RELATION KAPITEL 3. RELATIONENMODELL Abbildung 3.1: Attribute als Funktionen zwischen Objektmenge und verschiedenen Wertebereichen Das Attribut Nachnamen stellt eine Abbildung der Objekte von Angestellter in den schon für das Attribut Vornamen genutzten Wertebereich dar. Die Zuordnung im Einzelnen ist offensichtlich. Die Abteilungsbezeichnung wird durch Nummern realisiert. Die Nummern werden für unser einfaches Beispiel aus dem Wertebereich [1..10] genommen. Die Firma hat also maximal 10 Abteilungen. Die Zusammenfassung der Attributwerte aller Attribute ergibt ein sogenanntes Werte-Tupel (tupel). Dieses Wertetupel wird häufig auch als Datensatz (record) bezeichnet. Ein spezieller Datensatz repräsentiert damit ein Objekt (Objekt-Instanz, entity instance, entity) der Objektmenge. Bezüglich der Attributstruktur gleichartig darstellbare Objekte können zu Klassen zusammengefaßt werden. Man spricht von Objektklasse oder entity set. Die Zusammenstellung der Objekte einer Objektklasse entspricht einer Auflistung dieser gleich strukturierten Datensätze. Eine adäquate Darstellungsform ist die Tabelle. In unserem Beispiel ergibt sich zur Darstellung der Objektklasse Angestellter die in Tabelle 3.1 angegebene Form. Zur Verdeutlichung der Datensatzstruktur sind die einzelnen Spalten der Tabelle mit den Attributnamen überschrieben. Insofern ist eine Tabelle die natürliche Daten-Repräsentation einer Objektklasse oder eines Entity-Sets. Das Festlegen der zur Beschreibung der Objekte notwendigen Attribute (ein- Version 1.0 / 25. März c H.-G. Hopf

20 3.1. RELATION KAPITEL 3. RELATIONENMODELL Attribute Personal- Vorname Nachname Abteilungsnummer nummer 101 Fritz Meier 1 Objekt, Tupel, Datensatz 102 Hans Müller Uli Adam 2 Tabelle 3.1: Tabellendarstellung der Objektklasse Angestellter schließlich ihres Wertebereiches) ist Gegenstand des eingangs angesprochenen Abstraktionsprozesses und damit Teil des Modellierungsprozesses. Attribute können identifizierenden oder beschreibenden Charakter haben. Ein Attribut oder eine Gruppe von Attributen, mit der Eigenschaft, ein Objekt einer Objektklasse eindeutig festzulegen, bezeichnet man als identifizierendes Attribut oder identifizierende Attribute. Identifizierende Attribute werden zur Definition von sog. Schlüsseln, einem eindeutigen Identifikationsmerkmal (Identifikator) eines Objekts, herangezogen. Es kann mehrere derartige Attribute oder Attributgruppen geben, die eine Schlüsselfunktion haben, d.h. untereinander formal gleichwertig als alternative Schlüssel dienen können. Ein Primärschlüssel ist der zur Identifikation einzelner Objekte einer Objektklasse (unter Umständen willkürlich) ausgewählte Schlüsselkandidat. Beschreibende Attribute legen darüber hinaus weitere Eigenschaften der in der Objektklasse zusammengefaßten Objekte fest. Eine bestimmte Kombination von Werten für einen Satz von beschreibenden Attributen kann für mehrere Objekte einer Objektklasse gleichermaßen zutreffen. Für unser Beispiel der Objektklasse Angestellter ist ein identifizierendes Attribut die Personalnummer. Die Personalnummer soll als Schlüssel verwendet werden. Die Abteilungsbezeichnung hingegen ist ein beschreibendes Attribut. Das Attribut kann in verschiedenen Datensätzen den gleichen Wert annehmen. Die Abteilungsbezeichnung ist damit sicher ungeeignet um einen Angestellten der Firma zu identifizieren, jedoch beschreibt sie die Zugehörigkeit von Angestellten zu einer Abteilung. Ein Datensatz einer Tabelle ist formal betrachtet ein Element des kartesischen Produktes der den einzelnen Attributen zugewiesenen Wertebereiche. Eine Ausprägung der Objektklasse wird durch eine Teilmenge dieses kartesischen Produktes repräsentiert. Diese Teilmenge wird in der Mathematik auch als Relation bezeichnet. Eine Tabelle ist damit eine Repräsentation einer Relation. Die Begriffe Tabelle und Relation werden häufig synonym benutzt. Eine Kurznotation zur Darstellung von Relationen verzichtet auf die Angabe der Objektinstanzen und beschränkt sich darauf die Attributstruktur der Objekte der Objektklasse (Typdefinition) anzugeben. Der Primärschlüssel wird häufig durch Unterstreichung hervorgehoben. Üblicherweise geschieht dies in der Form: Version 1.0 / 25. März c H.-G. Hopf

21 3.2. INTEGRITÄTSBEDINGUNGEN KAPITEL 3. RELATIONENMODELL Tabellen-/Relationsname (identifizierende Attribute, beschreibende Attribute) In unserem Beispiel lautet die Relation Angestellter in Kurznotation: Angestellter (Personalnummer, Vorname, Nachname, Abteilungsnummer) In einem Relationenmodell werden alle zur Beschreibung eines Modellierungsprojektes notwendigen Informationen in Form von Relationen angegeben. Durch Relationen repräsentierte Objekte können miteinander in Beziehung stehen. Diese Beziehung wird durch aufeinander bezogene Attribute realisiert: ein Attribut der einen Relation nimmt einen Wert eines Schlüsselattributes einer anderen Relation an. Man bezeichnet ein Attribut, das in einer anderen Relation Schlüsselfunktion besitzt, als Fremdschlüssel. In unserem Beispiel werden Angestellte in der Relation Angestellter über die Personalnummer, Abteilungen in der Relation Abteilung über eine Abteilungsnummer identifiziert. Angestellter (Personalnummer, Vorname, Nachname, Abteilungsnummer ) Abteilung ( Abteilungsnummer, Abteilungsbezeichnung, Personalnummer Abteilungsleiter, Umsatz, Abteilungsnummer übergeordnete Abteilung, Gebäude) Angestellte sind Abteilungen zugeordnet. Die Verbindung zwischen den Relationen Angestellter und Abteilung wird über das Attribut Abteilungsnummer hergestellt. In der Relation Angestellter ist damit das Attribut Abteilungsnummer Fremdschlüssel. 3.2 Integritätsbedingungen Der Begriff Integrität 1 bezieht sich auf den Grad an Korrektheit oder Exaktheit der abgelegten Information. Man kann versuchen Integrität durch Formulierung von Bedingungen, deren Einhaltung beachtet, überwacht oder erzwungen wird, zu erreichen oder zumindest zu unterstützen. Integritätsbedingungen können z.b. formuliert werden als Bedingungen bezüglich der Einhaltung des Attribut-Wertebereichs Schlüssel und Fremdschlüssel von Relationen und Abhängigkeiten zwischen den Attributen einer Relation Zwei Integritätsbedingungen bezüglich Schlüssel und Fremdschlüssel sollen explizit aufgeführt werden: 1 Makellosigkeit, Unbescholtenheit Version 1.0 / 25. März c H.-G. Hopf

22 3.3. BEISPIEL KAPITEL 3. RELATIONENMODELL Abbildung 3.2: Integritätsbedingungen: Objektintegrität, referentielle Integrität Objektintegrität: Für jeden Tabelleneintrag als Datenabstraktion eines existierenden realen Objekts muß es einen wohldefinierten Schlüssel zur eindeutigen Identifikation geben. Das bedeutet, daß Schlüsselattribute keine undefinierten Werte (sog. Null-Werte 2 ) annehmen dürfen. Null- Werte in Schlüsselattributen von Relationen sind verboten. Referenzielle Integrität: Mit einem Fremdschlüssel wird auf ein Objekt einer anderen Objektklasse verwiesen. Dieses referenzierte Objekt muß existieren. Deshalb gilt: Jeder vom Null-Wert verschiedene Wert für einen Fremdschlüssel muß einem existierenden Schlüsselwert in der referenzierten Tabelle entsprechen. Integritätsbedingungen geben in gewissem, eingeschränkten Umfang Aufschluß über die Bedeutung von Daten. 3.3 Beispiel Ein Beispiel für ein Relationenmodell zur Beschreibung einer Firmenorganisation ist in Abbildung 3.3 formal und in Abbildung 3.4 diagrammatisch angegeben. 2 Ein Null-Wert bezeichnet einen noch unbekannten oder nicht definierten Attributwert. Version 1.0 / 25. März c H.-G. Hopf

23 3.3. BEISPIEL KAPITEL 3. RELATIONENMODELL Angestellter (Personalnummer, Vorname, Nachname, Gehalt, Geburtsdatum, Telephonnummer, Abteilungsnummer, Stadt, Straße, PLZ) Manager (Personalnummer, unterschriftsberechtigt bis) Ingenieur (Personalnummer, Fachgebiet) Techniker (Personalnummer, Fachgebiet) Sekretärin (Personalnummer, Anschläge pro Minute) Aufsichtsrat (Personalnummer, Bereich, Funktion) Betriebsrat (Personalnummer, Funktion) Gewerkschaftsmitglied (Personalnummer, Gewerkschaft, Funktion) Gremiumsmitglied (Personalnummer Funktion, Beschreibung) Projekt (Projektnummer, Projektname, Kostenstelle) Fachgebiet (Fachgebietsidentifikator, Bezeichnung) Labor (Laboridentifikator, Laborbezeichnung) Stadt (Name, Bundesland) Bundesland (Bezeichnung) Abteilung (Abteilungsnummer, Abteilungsbezeichnung, Umsatz, Personalnummer Abteilungsleiter) Hauptabteilung (Hauptabteilungsnummer, Hauptabteilungsbezeichnung, Personalnummer Hauptabteilungsleiter) Ressource (Ressourcenidentifikator, Bezeichnung, Personalnummer) Berufsverband (Berufsverbandsidentifikator, Bezeichnung) ist Mitglied von (Personalnummer, Berufsverbandsidentifikator) setzt ein (Personalnummer, Projektidentifikator, Fachgebietsidentifikator) wird durchgeführt in (Personalnummer, Projektidentifikator, Laboridentifikator) Abbildung 3.3: Relationenmodell zur Darstellung einer Firmenorganisation: formale Darstellung Version 1.0 / 25. März c H.-G. Hopf

24 3.3. BEISPIEL KAPITEL 3. RELATIONENMODELL Abbildung 3.4: Relationenmodell zur Darstellung einer Firmenorganisation: diagrammatische Darstellung Version 1.0 / 25. März c H.-G. Hopf

25 3.4. ÜBUNGEN KAPITEL 3. RELATIONENMODELL 3.4 Übungen Das Übungsbeispiel beschäftigt sich mit der Verwaltung eines Kinounternehmens. Ein Kinounternehmen besteht heute vielfach aus verschiedenen, über eine Stadt verteilten oder auch in mehreren Städten angesiedelten Lichtspielhäusern (Kinos). Für das gesamte Unternehmen besteht ein zentraler Einkauf von Filmen. Für die einzelnen Kinos wird der Spielplan zentral festgelegt. In einem Kinokomplex werden nicht selten in zwölf oder mehr Kinosälen in der Woche ca. 16 verschiedene Hauptfilme gezeigt. Entsprechend aufwendig sind Planungsaktivitäten und die Organisation des Spielbetriebs. Um für Besucher attraktiv zu sein, ist der Kinobetrieb ergänzt durch ein in den Lichtspielhäusern angesiedeltes zusätzliches Freizeit- und Serviceangebot. Zu diesem Angebot gehört beispielsweise ein Kabarett- und Kleinkunstprogramm, Boutiquen und Cafe- oder Restaurantbetriebe. Insbesondere für das Bühnenprogramm muss ebenfalls die Planung und Organisation geleistet werden. Kundeninformation und Werbung sind von großer Bedeutung. Ein Kunde soll natürlich angemessen mit Informationen über das Kino- bzw. Bühnenprogramm versorgt werden. Zusätzlich soll aber auch Information zu den einzelnen Filmen, z.b. Zusammenfassungen oder Besetzungslisten, Angaben zum Regisseur oder zu der Produktionsfirma, zu den Drehorten oder den Kosten des Films gemacht werden können. Selbstverständlich müssen auch Reservierungen unter Angabe des gewünschten Kinoplatzes sowohl an der Kinokasse als auch telephonisch und für einen längeren Zeitraum im voraus möglich sein. 1. Erstellen Sie eine Informationssammlung zum Thema Verwaltung eines Kinounternehmens! 2. Entwickeln Sie aus der Informationssammlung ein logisches Datenmodell in Form eines relationalen Schemas (Relationenmodell)! Version 1.0 / 25. März c H.-G. Hopf

26 Literaturverzeichnis [BAR 92 ] [BOH 72 ] [CHE 76 ] [FLE 89 ] [HEU 92 ] [HOP 90 ] Barker, R.: Case Method: Entity-Relationship-Modellierung; Addison-Wesley, Bonn, 1992; Otmar Bohusch: Lexikon der grammatikalischen Terminologie; Verlag Ludwig Auer, Donauwörth, 1972 Chen, P. P.-S.: The Entity-Relationship Model - Toward a Unified View of Data; ACM Transactions on Database Systems, Vol. 1 No. 1 March 1976 Fleischhauer, P.; Rouette, L.: Wissen, Information, Daten - Versuch einer begrifflichen Klarstellung und Abgrenzung; Computer Magazin Wissen, Heft 101, 1989; Heuer, A.: Objektorientierte Datenbanken - Konzepte, Modelle, Systeme; Addison-Wesley, Bonn, 1992; Hopf, H.-G.: Datenverarbeitungssysteme und -Anlagen; Vorlesungsskript, Georg-Simon-Ohm-Fachhochschule Nürnberg, WS 1989/90; [HOP 92 ] Hopf, H.-G.: Datenmodellierung; Vorlesungsskript, Georg- Simon-Ohm-Fachhochschule Nürnberg, 1992; [KIM 95 ] [RAM 91 ] [RAU 95 ] [ROC 90 ] Kim, Young-Gul; March, Salvatore T.: Comparing Data Modelling Formalisms; Communication of the ACM, June 1995, Vol. 38, No. 6, p 103; Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William: Object-Oriented Modelling and Design; Prentice - Hall, Englewood Cliffs, New Jersey, 1991; Rauh, Otto: ERM ded - eine Erweiterung des Entity-Relationship- Modells zur Modellierung deduktiver Informationssysteme; Informatik Forschung und Entwicklung (1995) 10; ; Rochfeld, A.; Morejon, J.; Negros, P.: Inter-Relationship Links in E-R Model; Proceedings of the 9th International Conference, 8-10 October, 1990, Lausanne Switzerland 25

27 LITERATURVERZEICHNIS LITERATURVERZEICHNIS [SCHN 86 ] [STI 91 ] [TEO 86 ] [TEO 90 ] Schneider, Hans-Jochen (Hrsg.): Lexikon der Informatik und Datenverarbeitung; Oldenbourg-Verlag, München, 1986; Stickel, Eberhard: Datenbankdesign - Methoden und Übungen; Verlag Dr. Th. Gabler, Wiesbaden 1992; Teorey, T.J.; Yang, D.; Fry, J.P.: A logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model; Computing Surveys, Vol. 18, No. 2, June 1986 Teorey, Toby J.: Database Modelling and Design - The Entity- Relationship Approach; Morgan Kaufmann Publishers, Inc. San Mateo, California, 1990, ISBN Version 1.0 / 25. März c H.-G. Hopf