Jürgen Spielberger. Datenmodellierung und relationale Datenbanktechnik. für Entwickler und Anwender. Dipl. Informatik-Ing. ETH lic. oec. inform.

Transkript

1 Jürgen Spielberger Dipl. Informatik-Ing. ETH lic. oec. inform. HSG Datenmodellierung und relationale Datenbanktechnik für Entwickler und Anwender Jürgen Spielberger Version , 1. September 2001

2 2 Inhaltsverzeichnis Aufbauschema des Buches: Inhaltsverzeichnis (ab Seite 3) Inhaltsverzeichnis (ab Seite 3) Teil 1: Einführung (ab Seite 9) Einführung in die Thematik der Datenmodellierung und Datenbanktechnik Teil 2: Konzeptionelle Datenmodellierung (ab Seite 25) Theorie und Übungen zum Erstellen konzeptioneller Datenmodelle Teil 3: Internes Datenmodell (ab Seite 87) Theorie und Übungen zu Datenbanktechnik und zum Erstellung des internen/physischen Datenmodells Teil 4: Fallbeispiel (ab Seite 135) Umfassende Übung zu den behandelten Themen Anhang (ab Seite 145) Musterlösungen zu sämtlichen Aufgaben, Checkliste, Erläuterung der Fragetypen, Literaturverzeichnis, Index Auf 213 Seiten Theorie und Übungen 950 Minuten Übungen in 14 Bearbeitungsaufgaben 116 Checkfragen (Multiple Choice) 81 Figuren und Zeichnungen 65 Tabellen und Relationenmodelle

3 Inhaltsverzeichnis 3 Inhaltsverzeichnis Teil 1: Einführung 9 1. Zielsetzung, Zielgruppe, Voraussetzungen und Aufbau Zielsetzung Zielgruppe, Voraussetzungen Aufbau des Dokuments Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Dateiverwaltungssysteme Separate Dateiverwaltung Gemeinsame Dateiverwaltung Datenbanksysteme Hierarchische Datenbanksysteme Netzwerkartige Datenbanksysteme Relationale Datenbanksysteme Begriff Datenbank Eigenschaften von Datenbanken Checkfragen Fragetyp A, Einfachauswahl Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Einführung in die Datenmodellierung Begriff Datenmodell Gliederung des Datenmodells gemäss ANSI-SPARC Begriff und Zielsetzung der Datenmodellierung Datenmodellierung als Teil des Informatikprojektes Checkfragen Fragetyp A, Einfachauswahl Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Teil 2: Konzeptionelle Datenmodellierung Elementarinstrumente des konzeptionellen Datenmodells Entität, Entitätsmenge Beziehung, Beziehungsmenge Die Beziehung im Entity-Relationship-Modell Erweitertes Relationenmodell, Beziehungs-Variante des Entity-Relationship-Modells Vor- und Nachteile beider Ansätze Assoziationstypen, Beziehungstypen Verhalten bei Datenbank-Transaktionen Wertebereich Elementarer Wertebereich Strukturierter Wertebereich NULL-Werte Typenbindung Attribut Entitätsschlüssel, Schlüsselkandidat Fremdschlüssel Checkfragen Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben KontoSys, Kontoverwaltungs-System RezeptSys, Rezeptverwaltungs-System... 45

4 4 Inhaltsverzeichnis 5. Normalisierung von Entitätsmengen im konzeptionellen Modell Normalform Normalform Normalform Checkfragen Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben Normalisierung Projektverwaltung Normalisierung Buchhandelssystem Normalisierung Wagenvermietung Verbundinstrumente des konzeptionellen Modells Hierarchie Beziehungsstruktur Rekursion Aggregation Spezialisierung/Generalisierung Wertetabelle Variante Referenzierung Checkfragen Fragetyp A, Einfachauswahl Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben Liversys, Liegenschafts-Verwaltungs-System Transpo, Transport-Verwaltungs-System Spezielle Problemstellungen des konzeptionellen Modells Mengenprobleme im Verbundinstrument Beziehungsstruktur Historisierung von Daten Periodenstempel Gültig-Ab- und Lösch-Zeitstempel Auslagerung historischer Daten Auslagerung der Änderungen Migration von Informationen Verdichtung von Informationen Integrität im konzeptionellen Modell Datenkonsistenz im konzeptionellen Modell Datenschutz im konzeptionellen Modell Checkfragen Fragetyp A, Einfachauswahl Fragetyp K, mehrfache Entscheidung Teil 3: Internes Datenmodell Datenbanktechnik, Softwarekomponenten eines Datenbanksystems Externspeicherverwaltung Systempufferverwaltung Record- und Zugriffspfadverwaltung Recordverwaltung Zugriffspfadverwaltung Zugriffsverfahren mit invertierten Listen Baumstrukturierte Zugriffsverfahren, B- und B*-Baum Zugriffsverfahren mit Schlüsseltransformation Entitätenverwaltung Metadatenbank Transaktionsverwaltung Optimistisches Verfahren Pessimistisches Verfahren Zeitstempel-Verfahren Transaktionslogik in verteilten Datenbanksystemen Integritätssicherung im Datenbanksystem (interne Ebene)

5 Inhaltsverzeichnis Datenkonsistenz Datensicherheit, Recovery Datenschutz, Kryptographie Cursor-Verwalter Entitätsmengenverwaltung Zugriffspfadoptimierer, Optimizer Datenbanksprachen Checkfragen Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben Zugriffspfade Aufgabe: Invertierte Liste Aufgabe: HASH Aufgabe: B-Baum Metadatenbank Deadlock im pessimistischen Verfahren Locking im pessimistischen Verfahren Ablaufplan Transaktionslogik und Programme Internes Datenmodell Herleitung des internen Datenmodells für ein vorgegebenes Datenbanksystem Bestimmen der Zugriffspfade Mögliche Zugriffspfade bestimmen Zugriffspfad-Effizienz bestimmen Physische Organisation Denormalisierung zur Performance-Verbesserung Checkfragen Fragetyp K, mehrfache Entscheidung Verteilung von Daten Vorteile und Nachteile verteilter Datenbanksysteme Eigenschaften verteilter Datenbanksysteme Checkfragen Fragetyp K, mehrfache Entscheidung Teil 4: Fallbeispiel Fallbeispiel TTW Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (Bottom-Up) Ermittlung des Datenmodells zur Anwendung TravelSys (55 Minuten) Normalisierung des Datenmodells (25 Minuten) Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (Top-Down) Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste) (25 Minuten) Zeitabhängige Daten und Varianten von Daten in Datenmodellen (40 Minuten) Mitarbeiterstamm, Spezialisierung/Generalisierung (Is-A-Struktur) (20 Minuten) Vorgehensentscheid Dateiverwaltung oder DBMS (20 Minuten) Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation Internes Schema (15 Minuten) Physische Speicherorganisation (5 Minuten) Meta-Entitätstypen, Data-Dictionary (20 Minuten) Anhang Tabellen, Verzeichnisse Farben, Sonderzeichen und deren Bedeutung Synonyme unterschiedlicher Systeme und Modelle Kürzel der Datenmodellierung und Datenbanktechnik Kontrollfragen zum konzeptionellen Datenmodell

6 6 Inhaltsverzeichnis 14. Fragetypen der Checkfragen Lösungen zu den Aufgaben Checkfragen: 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Checkfragen: 3. Einführung in die Datenmodellierung Fragetyp A, Einfachauswahl Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Checkfragen: 4. Elementarinstrumente des konzeptionellen Datenmodells Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben: 4. Elementarinstrumente des konzeptionellen Datenmodells KontoSys, Kontoverwaltungs-System RezeptSys, Rezeptverwaltungssystem Checkfragen: 5. Normalisierung von Entitätsmengen im konzeptionellen Modell Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben: 5. Normalisierung von Entitätsmengen im konzeptionellen Modell Projektverwaltung Buchhandelssystem Wagenvermietung Checkfragen: 6. Verbundinstrumente des konzeptionellen Modells Fragetyp A, Einfachauswahl Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben: 6. Verbundinstrumente des konzeptionellen Modells Liversys Transpo Checkfragen: 8. Integrität im konzeptionellen Modell Fragetyp A, Einfachauswahl Fragetyp K, mehrfache Entscheidung Checkfragen: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems Fragetyp A, Einfachauswahl Fragetyp B, Zuordnung Fragetyp E, kausale Verknüpfung Fragetyp K, mehrfache Entscheidung Bearbeitungsaufgaben: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems Zugriffspfade Metadatenbank Deadlock im pessimistischen Verfahren Locking im pessimistischen Verfahren Ablaufplan Transaktionslogik und Programme Checkfragen: 10. Internes Datenmodell Fragetyp K, mehrfache Entscheidung Checkfragen: 11. Verteilung von Daten Fragetyp K, mehrfache Entscheidung Fallbeispiel TTW Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (Bottom-Up) Ermittlung des Datenmodells zur Anwendung TravelSys Normalisierung des Datenmodells Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (Top-Down) Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste) Zeitabhängige Daten und Varianten von Daten in Datenmodellen Mitarbeiter-Stamm, Spezialisierung/Generalisierung Vorgehensentscheid Dateiverwaltung oder DBMS Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation Internes Schema Physische Speicherorganisation Meta-Entitätstypen, Data-Dictionary

7 Inhaltsverzeichnis Literatur Index 212

8

9 Teil 1: Einführung 9

10 10 Teil 1: Einführung

11 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Zielsetzung, Zielgruppe, Voraussetzungen und Aufbau 1.1. Zielsetzung Dieses Dokument ermöglicht dem Leser folgende zwei Ziele zu erreichen: 1. Das Dokument vermittelt die Grundlagen der Datenmodellierung, so dass der Leser in der Lage ist, selbständig ein Datenmodell zu entwickeln und/oder dieses auf dessen Zweckmässigkeit und Qualität hin zu überprüfen. In den weiterführenden Kapiteln werden Spezialfälle und deren möglichen Lösungen gezeigt, so dass der Leser auch für komplexere Probleme der Modellierung gerüstet ist. 2. Des Weiteren soll dem Leser gezeigt werden, mittels welcher Methoden relationale Datenbanksysteme ihre Aufgaben lösen. Diese Kenntnisse dienen als Basis um zu zeigen, welche technischen Faktoren beim Einsatz eines Datenbanksystems zu berücksichtigen sind. Danach ist der Leser in der Lage, ein Datenmodell physisch auf einem Datenbanksystem zu realisieren und das Datenbanksystem in Programmen und Abfragen optimal zu nutzen (Effizienz, Performanz) bzw. dessen Leistung gezielt zu beeinflussen. Um diese Ziele zu erreichen, sind nach jedem Kapitel entsprechende Übungen und/oder Check-Fragen eingebettet. Diese Übungen ermöglichen es, den Inhalt der Kapitel selbständig zu erarbeiten und an konkreten, praxisorientierten Fällen zu vertiefen. Eine Erläuterung zu den Check-Fragen finden Sie im Kapitel '14. Fragetypen der Checkfragen' auf Seite Zielgruppe, Voraussetzungen Diese Dokumentation richtet sich an Entwickler (Informatik, Organisation,...) und Anwender mit folgenden Aufgaben: 1. Datenmodellierung: Entwickler und Anwender, welche in ihrer Arbeit Datenmodelle lesen, erstellen oder verwalten müssen. 2. Programmierung: Entwickler, welche Programme und Abfragen für Datenbanksysteme entwickeln und warten. 3. Tuning: Entwickler, welche das Leistungsverhalten von Datenbanksystemen gezielt beeinflussen müssen. Zur Bearbeitung dieses Dokumentes sind folgende Kenntnisse empfohlen: 1. EDV-Grundkenntnisse. 2. Einfache Kenntnisse von Datenbanksystemen oder Dateiverwaltungssystemen (aber keine Kenntnisse der Datenmodellierung) Um einen Überblick über die wichtigsten verwendeten Begriffe zu erhalten, empfiehlt sich an dieser Stelle ein kurzes Studium des Kapitels '13.2. Synonyme unterschiedlicher Systeme und Modelle' auf Seite Aufbau des Dokuments Das Dokument ist derart aufgebaut, dass alle Kapitel gelesen und verstanden werden können, ohne über Kenntnisse der nachfolgenden Kapitel verfügen zu müssen. Damit kann das Dokument vom Start bis zum Ende linear durchgearbeitet werden. Dies bedingt allerdings, dass stellenweise die Erläuterung gewisser Grundkenntnisse der detaillierten Behandlung des Themas vorgezogen wird. Weiter sind Kapitel und Abschnitte, welche für den Anfänger ungeeignet sind, das heisst, welche bereits Erfahrungen in der Datenmodellierung benötigen oder welche detaillierte Ausfüh- Teil 1: Einführung

12 12 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank rungen zu einem bestimmten Thema enthalten, mit dem Zeichen gekennzeichnet. Dadurch kann der Anfänger zunächst die Grundkenntnisse erarbeiten und später die Detailkenntnisse gezielt nacherarbeiten. 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank In diesem Kapitel wird die technologische Entwicklung von Datenbanksystemen gezeigt. Es eignet sich daher speziell für Leser, welche keine oder wenig Erfahrung mit Datenbanksystemen haben, um sich einen ersten Überblick zu verschaffen und den Einstieg zu erleichtern. Die Gliederung der Systeme, wie sie in den folgenden Unterkapiteln vorgenommen wird, kann in der Praxis nicht derart streng erfolgen. In der Realität sind die Grenzen verschwommen und können sich die gezeigten Eigenschaften vermischen. Die Beispiele müssen daher als Extreme einer kontinuierlichen technischen Entwicklung angesehen werden. Um den Vergleich und den Einstieg in die unterschiedlichen Systeme zu erleichtern, sei an dieser Stelle auf die Tabelle auf Seite 148 im Kapitel '13.2. Synonyme unterschiedlicher Systeme und Modelle' hingewiesen, in welcher die Begriffe der verschiedenen Systeme und Modelle einander gegenübergestellt werden Dateiverwaltungssysteme Separate Dateiverwaltung Dateiverwaltungssysteme sind in unserem Sinne keine Datenbanksysteme. Bei primitiven Dateiverwaltungssystemen werden Dateien durch Programme verarbeitet, welche wieder Dateien als Ausgabe erzeugen. Die Dateien fliessen dabei förmlich durch die Programme. Der Datenfluss kann dabei mittels sogenannter Datenflussdiagramme grafisch dargestellt werden. Dieser Datenfluss beschreibt den logischen Ablauf (Reihenfolge) der Programme. Die innere Struktur der Datei wird hierbei im Programm selbst definiert (z.b. als 'File Of Record'). Müssen Änderungen in der Datenstruktur vorgenommen werden, so müssen sämtliche Programme, welche eine Datei dieser Struktur verarbeiten, angepasst werden. Zusätzlich treten bei dieser Verarbeitung viele Redundanzen (Mehrfachspeicherung der selben Information) auf. Dateiverwaltungssysteme mit dieser Arbeitsweise werden separate Dateiverwaltungssysteme genannt, weil der Zugriff auf die Daten durch jedes Programm selbständig erfolgt. Diese Art der Programmierung war zu Beginn in der Informatik der Normalfall und entsprach den technischen Gegebenheiten jener Zeit Gemeinsame Dateiverwaltung Um die schwerwiegendsten Mängel dieser primitiven Dateiverwaltungssysteme zu korrigieren, wurden in der Folge zentrale Programmmodule erstellt, welche den Zugriff auf die Daten handhabten. Diese Systeme werden daher gemeinsame Dateiverwaltungssysteme genannt. Zentrale Komponente dieser Systeme ist eine Sammlung von Programmmodulen (Bibliothek), welche den Zugriff auf die Daten steuern. Die Programme greifen dabei nicht mehr selbst und direkt auf die Daten zu, sondern nur noch mittels der Programmmodule (z.b. 'Les e_name[ I N: - Kunden_Nr, OUT: Kunden_Name] '). Je nach Reife des Dateiverwaltungssystems werden damit bereits beträchtliche Vorteile errungen. Prinzipiell könnten damit alle unerwünschten Redundanzen verhindert werden. Die eigentlichen Programme müssten keinerlei Strukturinformationen (Rekordstruktur) beinhalten. Systeme mit gemeinsamer Dateiverwaltung sind in der Regel auf bestimmte Aufgabenbereiche zugeschnitten (z.b. Verwaltung von grafischen Objekten) und dabei durchaus leistungsfähig. Allerdings weisen diese Systeme weitere gravierende Mängel auf, welche deren Einsatz im Allgemeinen verunmöglichen (z.b. kein Mehrbenutzerbetrieb, keine Transaktionslogik, etc.). Teil 1: Einführung

13 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Datenbanksysteme Hierarchische Datenbanksysteme In einem nächsten Schritt wurden Datenbanksysteme (auch Datenbankmanagementsystem) (Englisch: Database Management System, Kurzform: DBMS) entwickelt, welche grundsätzlich unabhängig von vorgegebenen Aufgabenbereichen eingesetzt werden können. Diese Systeme betrachten die einzelnen Dateien dabei nicht nur als isolierte Einzelstücke, sondern berücksichtigen auch die Beziehungen zwischen den Dateien (z.b. zwischen dem Kunden und dessen Aufträgen). Hierarchische Datenbanksysteme sind die ältesten Systeme. Sie erlauben nur Beziehungen mit hierarchischem Charakter darzustellen, dabei kann die entstehende Datenstruktur als Baum dargestellt werden (siehe Figur: 'Datenmodell eines hierarchischen Datenbanksystem'). Bei hierarchischen Beziehungen kann ein übergeordneter Knoten mehrere untergeordnete Knoten haben, ein untergeordneter Knoten hat aber höchstens einen übergeordneten Knoten. Dadurch können Kunden Aufträge und Rechnungen haben, die Aufträge können aber nur den Kunden untergeordnet werden. Die Beziehungen zwischen den Daten werden hierfür in der Regel mittels physischer Adresszeiger (Pointer) erstellt. Darin widerspiegelt sich auch die Nähe dieser Systeme zur technischen Lösung. Die Verarbeitung der Daten erfolgt, indem in den Programmen diesen Adresszeigern gefolgt wird. Diese Verarbeitungsart in den Programmen wird Navigation genannt. Kunden Aufträge Rechnungen Auftragspositionen Figur 1: Datenmodell eines hierarchischen Datenbanksystems Mittels hierarchischer Systeme können komplexe Datenstrukturen aber nicht ohne gravierende Redundanzen abgebildet werden. Rein hierarchische Systeme waren daher auf Dauer den Anforderungen der Praxis nicht gewachsen. Hierarchische Datenbanksysteme in Reinkultur existieren daher nicht mehr. Ursprünglich hierarchische Datenbanksysteme wie IMS (Information Management System) bieten heute Erweiterungen, welche diesen schwerwiegenden Mangel beseitigen Netzwerkartige Datenbanksysteme Netzwerkartige Systeme eliminieren den entscheidenden Mangel, welcher den hierarchischen Systemen eigen war. Sie erlauben nicht nur hierarchische Datenstrukturen, sondern beliebige netzwerkartige Datenstrukturen (auch Plexstruktur genannt). Dadurch konnten in Datenbanksystemen erstmals Datenstrukturen ohne Redundanzen abgebildet werden. Überdies sind die netzwerkartigen Datenbanksysteme technologisch noch eng mit den hierarchischen Systemen verwandt. So wird in den Programmen zur Verarbeitung der Daten noch immer navigiert. Wichtigster Standard für Netzwerkdatenbanken ist das CODASYL-DBTG-Modell. Das CODASYL- DBTG-Modell enthält eine Datenbeschreibungskomponente und eine Datenmanipulationssprache. Teil 1: Einführung

14 14 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Kunden Artikel Aufträge Rechnungen Auftragspositionen Figur 2: Datenmodell eines netzwerkartigen Datenbanksystems Netzwerkartige Datenbanksysteme sind zwar effizient und ausgereift, doch hat eine Reihe von Mängeln dem relationalen Ansatz zum Durchbruch verholfen. So erfordert der Gebrauch der Datenbanksprache netzwerkartiger Systeme hohe Kenntnisse des realisierten Datenmodells und kann durch den Benutzer nicht angewendet werden. Auch sind Strukturänderungen der Daten mit grossem Aufwand verbunden, da die Daten mittels physischer Adresszeiger verknüpft werden Relationale Datenbanksysteme Während sich das hierarchische und das netzwerkartige Datenbanksystem an der technischen Lösung orientieren, löst sich das relationale Datenbanksystem vom technischen Ansatz. Ausgangsidee ist, dass alle (wirklich alle) Daten in Relationen (auch Tabellen genannt), ähnlich wie in einer Tabellenkalkulation, festgehalten werden (einfache Lösungen sind gute Lösungen). Die Darstellung der Daten mittels Relationen ist für Benutzer und Entwickler einfach und klar verständlich. Selbst die Verknüpfung der Daten erfolgt nicht mehr mittels physischer Adresszeiger, sondern mittels identischer Feldeinträge. So wird zum Beispiel in einem Auftrag (Datensatz, bzw. Tupel) mittels dem Attribut (Feld, bzw. Spalte) Kunden# auf den Kunden verwiesen, zu welchem der Auftrag gehört. Das Attribut Kunden# wird in der Relation Auftrag durch seine spezifische Aufgabe als Fremdschlüssel bezeichnet. Dieser Lösungsansatz wurde von Edgar F. Codd ausgearbeitet und mit einer fundierten Theorie ausgestattet: Kunden Kunden# Name PLZ Ort 1 Maier 8001 Zürich 2 Müller 8001 Zürich Rechnungen Rechnungs# Kunden# Datum Betrag März 2'778, März 211,50 Aufträge Auftrags# Kunden# Auftragsdatum März März März Teil 1: Einführung

15 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank 15 Artikel Artikel# Bezeichnung Preis Lagerbestand 2531 Monitor XP '090,00 6, Monitor XP '490,00 5, Diskette XDS 4,50 5'465, Tastatur HG/3 99,00 12,00 Auftragspositionen Auftrags# Artikel# Bestellmenge Rechnungsbetr ,00 1'090, ,00 1'490, ,00 198, ,00 112, ,00 99,00 Tabellen 1: Datendarstellung in relationalen Datenbanksystemen Ein Datenbanksystem ist, gemäss Codd [Codd 70], minimal relational, wenn dessen Funktionalität mindestens folgende drei Konzepte enthält: 1. Die gesamten Informationen sind einheitlich in Relationen (Tabellen) abgelegt. 2. Der Benutzer sieht keine Verweisstrukturen (keine physischen Adresszeiger) zwischen den Relationen. 3. Es sind Operationen zur Auswahl von Zeilen (Selektion) und Auswahl von Spalten (Projektion), sowie zur Verbindung (Join) von Relationeneinträgen definiert. Datenbanksysteme sind nur dann voll relational, wenn sie über die genannten Konzepte hinaus bestimmte Integritätsbedingungen selbständig überprüfen und wenn zusätzliche, ergänzende Datenbankoperationen zur Verfügung stehen. Die Struktur der Daten selbst kann natürlich auf die selbe grafische Art und Weise wie im Beispiel der netzwerkartigen Datenbank dargestellt werden. An dieser Stelle werden noch nicht alle Details relationaler Datenbanksysteme gezeigt. Diese werden später noch ausführlich besprochen Begriff Datenbank In der Praxis werden die Begriffe Datenbasis, Datenbanksystem (auch Datenbankverwaltungssystem) und Datenbank leider mehr oder weniger willkürlich verwendet, dabei sind die Begriffe klar definiert. Datenbank: Das Datenbanksystem (DBMS) bildet zusammen mit dem Datenbestand (Datenbasis) die Datenbank. Datenbanksysteme können in drei wesentliche Komponenten gegliedert werden. Diese Dreigliederung wird im Folgenden immer wieder verwendet werden: 1. Manipulationskomponente: Die Manipulationskomponente erlaubt die Verarbeitung der Benutzerdaten. Die Verarbeitung kann hierbei mengenorientiert (d.h. mehrere Datensätze pro Befehl) erfolgen (beispielsweise in SQL). Die Sprache zu dieser Komponente wird Datenmanipulations-Sprache, bzw. DML (Englisch: Data Manipulation Language) genannt. 2. Strukturierungskomponente: Mittels dieser Komponente wird die Struktur der Benutzerdaten verwaltet. Diese Strukturinformationen werden in der relationalen Datenbank ebenfalls in Relationen abgelegt. Die Sprache, mittels welcher die Struktur Teil 1: Einführung

16 16 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank definiert wird, wird Datendefinitions-Sprache oder Datenbeschreibungs-Sprache, bzw. DDL (Englisch: Data Definition Language oder Data Description Language) genannt. 3. Integritätskomponente: Diese Komponente stellt die Integrität (Widerspruchsfreiheit) der Daten sicher. So werden z.b. die Verknüpfung der Daten und benutzerdefinierte Integritätsregeln durch das Datenbanksystem kontrolliert. Die Sprache, mittels welcher die Integritätsregeln definiert werden, wird Datenkontroll-Sprache, bzw. DCL (Englisch: Data Control Language) genannt. Im Idealfall existiert eine einzige, einheitliche Sprache, welche alle drei Komponenten umfasst (z.b. SQL) Eigenschaften von Datenbanken In Datenbanken sind eine Reihe von wichtigen Eigenschaften integriert worden. Diese wichtigen Eigenschaften haben Datenbanksystemen zu ihrer weiten Verbreitung verholfen: Redundanzarme, strukturierte Datenbasis: Im Gegensatz zu Dateiverwaltungssystemen werden die Daten mit möglichst wenig Redundanzen (diese werden allenfalls zur Steigerung der Performance eingeführt) und in strukturierter Form abgelegt. Mehrbenutzerbetrieb: Datenbanksysteme koordinieren den gleichzeitigen, gemeinsamen Zugriff mehrerer Benutzer auf den selben Datenbestand und vermitteln dem Benutzer den Eindruck, die Daten als einziger zu verwenden. Integritätssicherung: Das Datenbanksystem kontrolliert die Daten auf Widerspruchsfreiheit (Datenkonsistenz), bewahrt vor physischer Verfälschung, bzw. Verlust (Datensicherheit) und schützt die Daten vor unerlaubten Zugriffen (Datenschutz). Verteilte Datenbanken: Daten können auf verschiedene Systeme (physisch und logisch) verteilt und dennoch durch alle Benutzer gemeinsam genutzt werden. Logische und physische Datenunabhängigkeit (Englisch: Data Independence): Strukturänderungen der Benutzerdaten (logische Datenunabhängigkeit, z.b. Änderungen an Feldformaten) und Änderungen der physischen Organisation der Daten (physische Datenunabhängigkeit, z.b. Speicherbereiche, Speichersatztypen, Indizes) haben, soweit möglich, keinen Einfluss auf bestehende Programme. Das 3-Schema-Modell von ANSI/SPARC (siehe '3.2. Gliederung des Datenmodells gemäss ANSI-SPARC' auf Seite 19) bezweckt im Kern die Realisierung der Datenunabhängigkeit. Teil 1: Einführung

17 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Checkfragen Die im folgenden verwendeten Fragetypen sind im Kapitel '14. Fragetypen der Checkfragen' auf Seite 151 erklärt. Die Lösungen zu den folgenden Checkfragen finden Sie auf Seite Fragetyp A, Einfachauswahl 1. Für hierarchische und netzwerkartige Datenbanksysteme gilt: A) Daten lassen sich immer redundanzfrei ablegen B) Sämtliche in der Realität auftretenden Datenstrukturen lassen sich darin 1:1 abbilden C) Die Daten werden immer baumstrukturiert abgelegt D) Strukturänderungen der Daten können nur mit grossem Aufwand vollzogen werden E) Benutzer können Daten einfach abfragen 2. Für das relationale DBMS gilt: A) Die DML wird zur Definition der Datenstruktur relationaler Datenbanksysteme verwendet B) Im relationalen Datenbanksystem werden alle Daten in Relationen festgehalten C) Die Daten werden baumstrukturiert abgelegt D) Der Fremdschlüssel identifiziert die Zeilen (Tupel) der Tabellen eindeutig E) Relationale Datenbanken können die physische Datenunabhängigkeit nicht gewährleisten 3. Bei welchem DBMS wird in den Programmen nicht navigiert? A) hierarchisches DBMS B) netzwerkartiges DBMS C) relationales DBMS D) integrative DBMS E) verteilte Datenbanken 4. In welchem Datenbanksystem werden Beziehungen auf der logischen Ebene nicht durch Adresszeiger (Pointer) dargestellt? A) hierarchisches DBMS B) netzwerkartiges DBMS C) relationales DBMS D) in keinem werden Beziehungen durch Adresszeiger dargestellt E) bei allen 5. Eine Datenbank ist... A) ein beliebiges Datenbankverwaltungssystem. B) ein relationales Datenbankverwaltungssystem. C) ein beliebiges Datenbankverwaltungssystem und dessen Datenbasis. D) ein relationales Datenbankverwaltungssystem und dessen Datenbasis. E) ein beliebiges Datenbankverwaltungssystem und die verwendete Hardware. 6. Eine DML ist... A) eine 3. Generationssprache. B) eine Menge von Tupeln. C) eine Sprache zur Manipulation von Datenbeständen. D) eine Datei zum Protokollieren von Zugriffen. E) eine Konsistenzbedingung. 7. Welche Eigenschaft weist eine Datenbank nicht auf? A) Trennung der Daten von den Anwendungen B) physische Datenabhängigkeit der Anwendungsprogramme C) dauerhafte Nutzung der Daten D) spezifische Datensichten für verschiedene Benutzer E) Strukturierung der Daten (kontrollierte Redundanz) Teil 1: Einführung

18 18 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank Fragetyp E, kausale Verknüpfung 1. In der heutigen Zeit empfiehlt sich in jedem Fall der Einsatz eines Datenbankmanagementsystems, weil die Integrität der Daten durch ein Datenbankmanagementsystem von Anfang an sichergestellt ist. A) +weil+ B) +/+ C) +/- D) -/+ E) -/ Fragetyp K, mehrfache Entscheidung 1. Welche Aussagen sind für die Dateiverwaltung im Vergleich zum DBMS korrekt? + - Die Dateiverwaltung hat einen kleineren Aufwand (Rechenzeit) während des Betriebs. Die Dateiverwaltung hat einen kleineren Aufwand (Arbeitszeit Entwickler) während der Entwicklung und Wartung von Anwendungen. Die Dateiverwaltung erlaubt ein einfacheres, besseres Sicherstellen der Integritätsanforderungen. Die mit Dateiverwaltungssystemen entwickelten Anwendungen sind flexibler gegenüber zukünftigen Entwicklungen. Teil 1: Einführung

19 3. Einführung in die Datenmodellierung Einführung in die Datenmodellierung 3.1. Begriff Datenmodell Der Begriff Datenmodell ist in der Praxis mit zwei voneinander abweichenden Bedeutungen belegt: 1. Datenmodellierungsmethode: Mittels dieser können Struktur, Inhalt und ergänzende semantische Aspekte des Datenbestandes entwickelt und festgehalten werden. Hierfür wurden in der Praxis unterschiedliche Methoden entwickelt. Eine der bekanntesten und verbreitesten Methoden ist das Entity-Relationship-Modell (mit vielen Varianten). 2. Datenstruktur: Die Datenstruktur zeigt den Aufbau der Daten eines Datenbestandes. Die Daten selbst werden in der Datenstruktur nicht festgehalten, lediglich deren Aufbau. In der Regel werden in der Datenstruktur auch logische Datenbanktransaktionen und Integritätsregeln definiert. Diese Doppelbelegung des Begriffs Datenmodell bereitet in der Praxis selten Schwierigkeiten. Die Bedeutung ergibt sich aus dem Kontext Gliederung des Datenmodells gemäss ANSI-SPARC Aufgrund der Komplexität sowie der unterschiedlichen Sichtweisen der im Modellierungsprozess betroffenen Personen (Anwender, Entwickler, DBA,...), drängt sich eine den Sichtweisen der Personen angepasste Darstellung und Gliederung des Modells (Datenstruktur) auf. Hierbei hat sich ein Modell (Datenmodellierungsmethode), das 3-Schema-Modell oder auch 3-Schema- Konzept des ANSI-SPARC-Komitees durchgesetzt (1977). Diese Datenmodellierungsmethode unterscheidet, wie der Name schon sagt, 3 Ebenen. Hierbei wird für jede Ebene eine der Sichtweise angepasste Datenstruktur bzw. Datenstrukturen erstellt. Hier erfolgt eine kurze Erklärung dieser Ebenen, später werden diese Ebenen anhand von Beispielen ausführlich behandelt. 1. Konzeptionelle Ebene: Diese stellt die gesamte Datenstruktur der Unternehmung dar (unternehmensweites Datenmodell). Dabei wird dieses Modell unabhängig vom zu verwendenden Datenbanksystem und Hardware erstellt. Damit ist das konzeptionelle Modell frei von technischen Details und kann auch erstellt werden, wenn das Zielsystem noch nicht bekannt ist. In dieser Ebene wird daher noch keine Rücksicht auf Performance oder Datenmengen genommen, diese Aspekte werden nur in der internen, physischen Ebene berücksichtigt (siehe unten). In der konzeptionellen Ebene wird versucht, ein möglichst realitätsnahes Datenmodell zu erstellen, welches keine Redundanzen aufweist. Auf dieser Ebene werden die Fachbegriffe der Anwendung eindeutig definiert. Dadurch bildet die konzeptionelle Ebene eine einheitliche, gemeinsame sprachliche Basis für alle am Projekt beteiligten Personen. Diese Ebene bildet in der Regel die Ausgangsbasis, um die Datenmodelle der beiden anderen Ebenen zu bilden. Innerhalb eines Projektvorgehens steht daher die Erstellung des konzeptionellen Datenmodells in aller Regel vor der Erstellung der Modelle der beiden anderen Ebenen. 2. Externe, logische Ebene: Auf der externen Ebene wird dargestellt, wie die Daten dem Benutzer präsentiert werden. Der Benutzer kann hierbei eine ganz andere Sichtweise auf die Daten einnehmen, als diese im konzeptionellen Modell abgelegt sind. Auch wird er in der Regel mehrere Sichten auf das selbe Modell einnehmen, je nach Problemstellung. Auf der externen Ebene werden daher für das konzeptionelle Modell viele, problemspezifische Teilsichten gebildet. In der Praxis wird für diese externen Sichten häufig der Fachbegriff View verwendet. Der Begriff logische Ebene sollte vermieden werden, da dieser nicht einheitlich verwendet wird. Teil 1: Einführung

20 20 3. Einführung in die Datenmodellierung 3. Interne, physische Ebene: Diese Ebene stellt dar, wie die Daten mit Hilfe des Datenbanksystems physisch organisiert werden sollen. Das interne Modell wird in der Regel vom konzeptionellen Modell abgeleitet. Wurden technische Aspekte beim Erstellen des konzeptionellen Modells vernachlässigt, so stehen diese jetzt im Zentrum der Überlegungen. Durch eine genaue Kenntnis des Datenbanksystems (z.b. ein relationales Datenbanksystem), der Datenmengen, der Zugriffshäufigkeiten und vieler Details mehr, wird versucht, ein 'optimales' internes Modell zu bilden. Die Performance der späteren Datenbankoperationen ist vom abgeleiteten internen (nicht aber vom konzeptionellen) Modell abhängig. Auch hier muss ein Kompromiss vieler widersprüchlicher Ziele gefunden werden. Eine wichtige Anforderung an Datenbanksysteme und Entwicklungsumgebungen ist es, diesen Optimierungsprozess auch noch während des normalen Betriebes zu ermöglichen und zu unterstützen. 1. externe Datensicht 2. externe Datensicht weitere externe Datensichten externe Ebene konzeptionelles Datenmodell konzeptionelle Ebene interne Datenstruktur (z.b. relational) physische, interne Ebene Figur 3: 3-Schema-Modell nach ANSI-SPARC Diese Gliederung des Datenmodells ist in den folgenden Kapiteln entscheidend. Vorerst wird einzig von der konzeptionellen Ebene Gebrauch gemacht, in welcher das konzeptionelle Datenmodell erstellt wird. Erst anschliessend wird, nach der Erklärung der Arbeitsweise von Datenbanksystemen, gezeigt, wie dieses konzeptionelle Modell in ein internes Modell abgebildet wird. Die Dreiteilung des Datenmodells wurde auch in viele Modellierungsmethoden als fester Bestandteil integriert. Im folgenden Bild werden die unterschiedlichen Datenmodelle der verschiedenen Ebenen an einem einfachen Beispiel gezeigt: Teil 1: Einführung

21 3. Einführung in die Datenmodellierung 21 externe Datensichten: Kunden Artikel Aufträge Aufträge Auftragspositionen konzeptionelles Datenmodell: Kunden Artikel Aufträge Rechnungen Auftragspositionen physisches, internes Datenmodell: Kunden Artikel Aufträge Rechnungen Auftragspositionen Figur 4: 3-Schema-Modell mit Beispielmodellen Aufträge Auftrags# Die externen Sichten erlauben dabei eine völlig individuelle Sicht auf die Daten. So könnte z.b. die zweite externe Sicht in Tabellenform dem Benutzer oder Entwickler wie folgt präsentiert werden: Kunden# Artikel# Bestellmenge Bezeichnung ,00 Monitor XP ,00 Monitor XP ,00 Tastatur HG/ ,00 Diskette XDS ,00 Tastatur HG/3 Tabellen 2: Externe Sicht in Tabellendarstellung Stellenweise wird gefordert, dass die interne Ebene eine weitere Gliederung erhalten soll, da in dieser Ebene Aspekte des Datenbanksystems auf der einen Seite und Aspekte des Betriebssystems und der Hardware auf der anderen Seite vermischt werden. Diese weitere Ver- Teil 1: Einführung

22 22 3. Einführung in die Datenmodellierung feinerung wird in den späteren Kapiteln nicht weiter berücksichtigt, da im folgenden nur allgemein Bezug auf Betriebssysteme und Hardware genommen werden kann. Auch spielt die Verteilung der Daten auf mehrere Datenbanksysteme eine zunehmend wichtige Rolle, so dass auch dieser Teilaspekt bei der Herleitung des internen Schemas berücksichtigt werden muss Begriff und Zielsetzung der Datenmodellierung In der Datenmodellierung wird festgelegt, wie die Daten einer Anwendung konzeptionell strukturiert werden, wie diese Datenstruktur mittels eines Datenbanksystems physisch organisiert wird und wie diese Daten dem Benutzer präsentiert werden. In diesem Vorgang müssen verschiedene, zum Teil in sich widersprüchliche Zielsetzungen und Bedürfnisse befriedigt werden, z.b.: Das Datenmodell muss die notwendigen Informationen der Anwendung vollständig darstellen können; dabei ist die Bestimmung der Systemgrenzen wichtig. Mit den gespeicherten Informationen im Datenmodell müssen sämtliche Funktionen (logische Datenbanktransaktionen, Geschäftsprozesse) der Anwendung ausführbar sein. Eine Modellierung ohne jegliche Kenntnis der grundsätzlich gewünschten Funktionalität der Anwendung kann daher kein zweckmässiges Datenmodell liefern. Das Datenmodell soll derart gebildet werden, dass auch zukünftige Bedürfnisse befriedigt werden können. Antwortzeiten und Datenmengen des Systems sind von Fall zu Fall ebenfalls zu berücksichtigen. Das Erstellen eines Datenmodells kann daher kein fest vorgegebener, streng mathematischer Ablauf sein. Es ist viel mehr ein kreativer Prozess, in welchem die Abstraktion eine wichtige Rolle spielt und in welchem immer und immer wieder die Vor- und Nachteile unterschiedlicher Lösungsansätze verglichen werden. Der Datenmodellierer muss daher über Kreativität, Abstraktionsvermögen, Ausdauer und Erfahrungen über Vor- und Nachteile unterschiedlicher Lösungsvarianten verfügen. Aus den vorhergehenden Erläuterungen geht auch hervor, dass es kein Standarddatenmodell geben kann, welches die Bedürfnisse einer bestimmten Branche unternehmensspezifisch abdeckt. Bei der Verwendung von Standarddatenmodellen stellen sich die selben Probleme, wie beim Einsatz von Standardsoftware. Das Standarddatenmodell sollte den entsprechenden Bedürfnissen des Unternehmens angepasst werden Datenmodellierung als Teil des Informatikprojektes Die Datenmodellierung ist meist Teil eines Informatikprojektes. Die Bildung des Datenmodells müsste daher korrekterweise im Umfeld eines Informatikprojektes dargestellt werden. Darauf wird in den folgenden Kapiteln aber verzichtet. Die Beschreibung der Datenmodellierung kann dadurch wesentlich kompakter und zielstrebiger erfolgen. Als Nachteil ergibt sich, dass die Berücksichtigung der durch das Datenmodell zu realisierenden logischen Funktionen (logische Datenbanktransaktion, Geschäftsprozesse) vernachlässigt wird und dadurch der Eindruck entstehen könnte, Datenmodellierung müsse die zu realisierenden Funktionen nicht kennen. In Tat und Wahrheit werden beim Modellieren im Hinterkopf aber immer auch diese Funktionen berücksichtigt. Ausserdem werden in den gezeigten Beispielen immer Freiräume offen bleiben, da nicht die gesamten notwendigen Informationen vorhanden sind und bei Problemen kein Anwender die offenen Fragen beantworten kann. Teil 1: Einführung

23 3. Einführung in die Datenmodellierung Checkfragen Die Lösungen zu den folgenden Checkfragen finden Sie auf Seite Fragetyp A, Einfachauswahl 1. Die Ebene des 3-Schema-Konzepts des ANSI-SPARC-Komitees, in welcher die Leistung des DBMS bzw. der Anwendung wesentlich beeinflusst wird, ist... A) die externe Ebene. B) die konzeptionelle Ebene. C) die interne Ebene. D) keine der Ebenen. E) alle Ebenen Fragetyp E, kausale Verknüpfung 1. Für das konzeptionelle Datenmodell sind leistungsbestimmende Überlegungen nicht erwünscht bzw. notwendig, weil der Benutzer bei der Entwicklung des konzeptionellen Modells einbezogen wird. A) +weil+ B) +/+ C) +/- D) -/+ E) -/- 2. Im konzeptionellen Datenmodell wird nicht auf die Datenmengen geachtet, weil erst im physischen Design (internes Datenmodell) die Datenstruktur mit Hilfsorganisationen zur Ablaufbeschleunigung ergänzt wird. A) +weil+ B) +/+ C) +/- D) -/+ E) -/- 3. Das konzeptionelle Datenmodell soll frei von technischen Details sein, weil das interne Datenmodell sich nicht aus dem konzeptionellen Datenmodell ableiten lässt. A) +weil+ B) +/+ C) +/- D) -/+ E) -/- 4. Die externe Ebene wird auch Benutzersicht (View) genannt, weil der Benutzer die Daten sieht, wie sie physisch gespeichert sind. A) +weil+ B) +/+ C) +/- D) -/+ E) -/- 5. Das konzeptionelle Datenmodell ist Grundlage für die Ableitung der physischen und externen Datenstrukturen, weil das konzeptionelle Datenmodell neutral gegenüber Einzelanwendungen und deren lokaler Sicht ist. A) +weil+ B) +/+ C) +/- D) -/+ E) -/ Fragetyp K, mehrfache Entscheidung 1. Zählen Sie die Merkmale des konzeptionellen Datenmodells auf: + - Berücksichtigt Hardwareüberlegungen Nach Ablauf dieser Phase steht das endgültige Datenbankdesign fest Dient als Grundlage für Entwurf und Betreuung der übrigen Schemata Realisiert eine erste Stufe der Zugriffsbefugnisse Teil 1: Einführung

24

25 Teil 2: Konzeptionelle Datenmodellierung 25

26

27 4. Elementarinstrumente des konzeptionellen Datenmodells Elementarinstrumente des konzeptionellen Datenmodells Beim Erstellen des konzeptionellen Datenmodells werden in sämtlichen Modellierungsmethoden wenige, einfache Elementarinstrumente verwendet. Einzelne Methoden bilden daraus dann weitere Grundstrukturen in ihrer Methodik. In diesem Abschnitt sollen vier Elementarinstrumente sowie deren Bedeutung eingeführt werden. Die Elementarinstrumente sind die Elemente zur Bildung der Datenstruktur (gleich Datenmodell). Die Begriffe Elementarinstrument und Verbundinstrument, wie sie später eingeführt werden, sind keine in der Datenmodellierung üblicherweise verwendeten Begriffe. Sie eignen sich aber dazu, den Sachverhalt besser zu gliedern, um damit die dahinterliegenden Konzepte besser zu verstehen. Die im folgenden Kapitel eingeführten vier Elementarinstrumente finden sich auch im Entity- Relationship-Modell (zu Deutsch etwa: Entitäten-Beziehungs Modell). Diese Begriffe werden im Folgenden immer dann verwendet, wenn sich die Ausführungen auf die konzeptionelle Ebene (siehe '3.2. Gliederung des Datenmodells gemäss ANSI-SPARC' auf Seite 19) beziehen. Die Tabelle '13.2. Synonyme unterschiedlicher Systeme und Modelle' auf Seite 148 erleichtert Ihnen den Einstieg, falls Sie diese Begriffe noch nicht kennen, aber mit einer anderen Systematik vertraut sind. Die Elementarinstrumente Wertebereich und Attribut werden in Unterkapiteln zusätzlich nach bestimmten Eigenschaften charakterisiert. Bei dieser Charakterisierung werden Eigenschaften, welche Teil des relationalen Modells sind, verwendet. Diese Typen erlauben ein grundlegenderes Verständnis des konzeptionellen Modells, sind in der Praxis verbreitet, sind Grundlage für die nachfolgende Normalisierung und erleichtern anschliessend die Herleitung des internen Modells. Dies ist Grund genug, diese bereits an dieser Stelle einzuführen Entität, Entitätsmenge Eine Entität (Englisch: Entity) ist ein einzelnes, in sich geschlossenes Objekt (Synonyme: Record, Tupel, Datensatz). Eine einfache, einleuchtende Definition ist schwierig, da eine klare Abgrenzung zu den anderen Instrumenten zum Teil schwer fällt und erst im konkreten Fall entschieden werden kann, was Entität ist und was nicht (dies wird im Weiteren noch besser verständlich). Häufig ist jedoch sofort klar, was in einem konkreten Projekt Entitäten sind. Mittels Beispielen von möglichen Entitäten soll der Begriff näher erläutert werden: Person: Der Kunde mit Kundennummer K , namens Müller Rolf Reales Objekt: Die Aktie der Firma ISAG mit Nummer Abstraktes Objekt: Das Aktiendepot mit Nummer DP-Akt des Kunden K Ereignis: Der Kauf der Aktie Nr für den Kunden K Entität: Eine Entität ist ein in sich geschlossenes Ding, für welches bestimmte Eigenschaften (Daten) gelten. Entitäten müssen mittels bestimmter Eigenschaften eindeutig identifiziert werden können. Bei der Modellierung werden nicht die einzelnen Entitäten dargestellt (was vollständig auch gar nicht möglich wäre), sondern es werden Mengen aus Entitäten gleicher Art gebildet, sogenannte Entitätsmengen (Englisch: Entity Set). Unseren Beispiel-Entitäten werden Entitätsmengen zugeordnet: Personen: Kunden Reale Objekte: Aktien Abstrakte Objekte: Aktiendepots Ereignisse: Aktienkäufe Teil 2: Konzeptionelle Datenmodellierung

28 28 4. Elementarinstrumente des konzeptionellen Datenmodells Entitätsmenge: Eine Entitätsmenge ist eine Menge von Entitäten, welche die selben Eigenschaften aufweisen. Die Entitätsmengen werden im grafischen Modell als Rechtecke dargestellt: Kunden Figur 5: Darstellung von Entitätsmengen In der Praxis werden die Begriffe Entität und Entitätsmenge leider häufig als Synonyme verwendet. Eine klare Trennung der Begriffe ist aber zweckdienlich, da z.b. eine Schulklasse eine einzelne Entität sein kann, aber auch eine Entitätsmenge, nämlich eine Menge von Schülern. Im zweiten Fall ist der Schüler die Entität. Auch die Namensgebung (Entitätsmengen werden im Modell benannt) ist nicht einheitlich. So werden Entitätsmengen im Singular (z.b. Kunde, Aktie,...) aber auch im Plural (z.b. Kunden, Aktien,...) benannt. Dies hat aber auf das Verständnis des Datenmodells meist wenig Einfluss. Wichtig für das Verständnis ist hingegen die Wahl eines sinnvollen, ausdrucksvollen Namens für die Entitätsmenge. Im Folgenden wird immer die Pluralform verwendet, da diese weniger missverständlich ist. Entitäten und Entitätsmengen können zusätzlich als unabhängige oder abhängige Entitäten bzw. Entitätsmengen klassifiziert werden. Eine abhängige Entität ist von der Existenz einer anderen Entität abhängig, kann also nur dann existieren, wenn diese referenzierte Entität auch existiert. Eine abhängige Entitätsmenge ist eine Menge von abhängigen Entitäten gleicher Art. Als Beispiel für eine abhängige Entität kann z.b. das Aktiendepot DP-Akt dienen. Es darf nur dann im System existieren, wenn diesem ein Kunde (Eigentümer) zugeordnet ist (Depots ohne Eigentümer gibt es nicht). Unterschiedliche Datenmodelle haben weitere Methoden zur Klassifizierung der Entitätsmengen entwickelt, diese lassen wir zunächst ausser Betracht. Später werden wir Entitätsmengen und die sie umgebenden Entitätsmengen betrachten und hierbei eine weitere Klassifizierung vornehmen Beziehung, Beziehungsmenge Bisher sind die Entitätsmengen ohne Verknüpfung zueinander dargestellt worden. Mittels Beziehungen (Beziehungsmengen = Menge aus Beziehungen der selben Art) werden diese Verknüpfungen im Datenmodell dargestellt. So wird zum Beispiel festgehalten, dass einem Depot immer ein Kunde zugeordnet ist und ein Kunde mehrere Depots haben kann. Leider findet man in der Praxis zwei voneinander abweichende Varianten zur Darstellung der Beziehungen zwischen den Entitätsmengen. In den folgenden zwei Unterkapiteln werden diese beiden Varianten erläutert Die Beziehung im Entity-Relationship-Modell Die Beziehungsmenge (Englisch: Relationship Set; der Begriff Relation wird im relationalen Modell für Entitätsmengen verwendet und wird daher im Entity-Relationship-Modell vermieden) stellt die Verknüpfung zwischen zwei oder mehr Entitätsmengen her. So wird z.b. mittels der Beziehungsmenge 'Depotinhalt' festgehalten, welche Aktien im Depot (eines Kunden) abgelegt sind (siehe Figur unten). Andererseits ist damit auch festgehalten, in welchen Depots eine bestimmte Aktie abgelegt ist. Entitätsmengen werden nicht direkt miteinander verbunden, sondern werden immer und ausschliesslich mittels einer Beziehungsmenge verknüpft. Zusätzlich wird festgehalten, wie viele Entitäten der einen Entitätsmenge einer Entität der anderen Entitätsmenge zugeordnet sind (und umgekehrt, Notation wird später erläutert). Grafisch werden Entitätsmengen als Rechtecke, Beziehungsmengen als Rhomben dargestellt. Teil 2: Konzeptionelle Datenmodellierung