RELATIONALE DATENBANKEN

Transkript

1 Bern University of Applied Sciences Engineering and Information Technology RELATIONALE DATENBANKEN P. Fierz Keywords: relationales Modell, relationale Algebra, Normalisierung, Entity-Relationship- Model, SQL, Transaktionen, Views, jdbc, Datenbankprozeduren, Triggers, objektrelationales Mapping [File rdb.tex, Date , Version 4.1] P. Fierz

2 Zusammenfassung Dieses Skript gibt einen überblick über das relationale Datenbankmodell. Insbesondere werden das relationale Modell (1970) von E.F. Codd und das Entity-Relationship-Modell (1976) von P. Chen beschrieben. Weiter wird die Umsetzung des relationalen Modells in konkrete Datenbansysteme insbesondere auch in der Sprache SQL behandelt. In einem zweiten Teil werden die Transaktionstheorie behandelt. Schliesslich wird auch die Programmierung in Datenbanken behandelt mit jdbc, Prozeduren und Triggers und schliesslich auch objektrelationales Mapping mit jpa.

3 Kapitel 1 Einführung Diese Einführung gibt einen raschen und oberflächlichen Einstieg in den ganzen Problembereich der Datenbanken. Die hier erwähnten Begriffe und Konzepte werden in den folgenden Kapiteln dieses Skriptes genauer erklärt. 1.1 Filesysteme In den Anfängen der Datenverarbeitung stand das programmgesteuerte Bearbeiten der Daten also das Rechnen, Zählen, Schreiben im Vordergrund. Dazu werden die Daten auf einzelnen Files (auf Platte oder Band) gespeichert. Der Zugriff auf die Files sowie die interne Organisation und Struktur der einzelenen Datensätzen wird vollständig von der Applikationssoftware geregelt. Je nach Filesystem werden dazu Hilfen wie Locking und Zugriffsmethoden (ISAM, B-Trees usw.) vom System zur Verfügung gestellt. Auch die Frage der gemeinsamen Nutzung von Daten durch mehrere Applikationen muss von diesen selbst geregelt werden (Konsistenz, Integrität usw). Diese Situation ist in der Abbildung 1-1 schematisch dargestellt. Zugriffsregelung Applikation 1 Applikation 2 Applikation 3 Daten Gemeinsame Daten Abbildung 1-1: Zugriff auf gemeinsamen Daten in einem Filesystem 1-1

4 Wir wollen nun kurz die Vor- und Nachteile eines klassischen Filesystems aufzählen. Vorteile Nachteile Im Allgemeinen ist der Entwicklungsaufwand für eine Applikation geringer. Da der Zugriff auf die Daten von der Applikation geregelt wird, ist in manchen Fällen eine gezielte und gute Optimierung der Zugriffe auf die Daten möglich. Die Daten weisen oft viel Redundanz auf. Die Daten einer Applikation sind häufig in einer zweiten Applikation nicht (oder nur schwer) nutzbar, weil die Strukturen nicht übereinstimmen. Da jede Applikation den Zugriff auf die Daten selber regelt, ist die Datenintegrität oft nicht gewährleistet. Da die Applikationsprogramme und die Daten fest verdrahtet sind, führen schon kleine Änderungen in der Datenstruktur zu einem erheblichen Programmieraufwand. 1.2 Definition Datenbank Im Gegensatz etwa zum Filesystem, wo jede Applikation den Zugriff auf bestehende Daten selber regelt (siehe Abschnitt 1.1), wird bei Datenbanken die Beschreibung der Datenstrukturen sowie der Zugriff auf die Daten zentralisiert. Zwischen dem Benutzer und den Daten steht ein Datenverwaltungssystem, das die Daten schützt und verschiedenen Benutzer zugänglich macht. Definition 1.1 [Datenbank] Eine Datenbank ist ein System zur Beschreibung, Speicherung und Wiedergewinnung von umfangreichen Datenmengen, die von mehreren Anwendungen ( gleichzeitig ) benutzt werden können. Sie besteht aus zwei Hauptteilen: Den eigentlichen Daten und Dem Datenbank-Management-System, (DBMS) das gemäss einer vorgegebenen Beschreibung Daten speichern, suchen, löschen oder ändern kann. Datenbank Daten Metadaten Hilfsdaten Datenbank Managementsystem Applikation1 Applikation 2 Applikation 3 Abbildung 1-2: Das DBMS steht zwischen Daten und Benutzern In der Abbildung 1-2 ist der allgemeine Aufbau einer Datenbank schematisch dargestellt. Unter Hilfsdaten verstehen wir alle Informationen, die zur Beschreibung der Benutzerdaten notwendig sind, sowie Zugriffshilfen (B-Trees, Hashtabellen usw.). 1-2

5 Im folgenden sind die wichtigsten Aufgaben des DBMS zusammengefasst. Das DBMS soll 1. verhindern, dass jeder Benutzer sich mit der inneren Organisation des Datenbestandes befassen muss, 2. verhindern, dass jeder Benutzer unkontrolliert an die Datenbstände gelangen kann und damit die Integrität der Daten gefährdet, 3. ermöglichen, dass für die Organisation der Daten günstige Voraussetzungen geschaffen werden, wobei diese Organisation bei Bedarf intern geändert werden kann, ohne dass dadurch an den Applikationen etwas verändert werden muss und 4. die Dauerhaftigkeit der gespeicherten Daten garantieren. Das heisst konkret, dass die Daten nach einem Systemabsturz konsistent wieder hergestellt werden können. Die Einführung eines zentralen DBMS hat folgende Konsequenzen: Vorteile Nachteile Zusammenfassung aller sonst mehrfach nötigen Funktionen für Datendefinition, Datenorganisation, Datenintegrität (Modularisierung). Geschützter Zugang zu Einzeldaten. Einheitliches Konzept. Bessere Entwicklungsfähigkeit. Abhängigkeit von zentralen Funktionen und Entscheiden. Bereitstellung und vor allem Pflege und Wartung des Datenbank-Management- Systems (wird zwar heute ab der Stange eingekauft). 1.3 Eigenschaften einer Datenbank Aus den obigen Überlegungen können wir folgende charakteristische Eigenschaften einer Datenbank ableiten ([Zeh89]). Diese werden durch die im nächsten Abschnitt vorgestellte Datenbankarchitektur auch sehr gut unterstützt. Strukturierung der Daten Der Datenbestand hat einen überschaubaren inneren Aufbau, so dass sich ein Benutzer auf bestimmte Daten und Datengruppen beziehen kann. Ungeordnete Mehrfachspeicherung derselben Daten ist nicht möglich. Trennung der Daten von den Anwendungen Die Trennung der Daten und ihrer physischen Organisation von den Anwendungen ermöglicht ein beidseitig weitgehend unabhängiges Arbeiten. Das bedeutet: Datenunabhängigkeit Die Anwendungsprogramme sind datenunabhängig, d.h. interne Reorganisationen innerhalb des Datenbanksystems tangieren die Anwendungsprogramme nicht (siehe auch 1.5). 1-3

6 Flexibilität Die Datenbank ist leicht erweiterbar. Neue Bedürfnisse der Benutzer an die Daten sollen nachträglich befriedigt werden können. Datenintegrität Die zur Wahrung der Datenintegrität wichtigsten Massnahmen sind die Eingabekontrolle (Datenkonsistenz), die Datensicherung und der Datenschutz. Zeitliche Persistenz Die Daten müssen dauerhaft nutzbar sein. Das heisst, sie sind nicht an die Lebensdauer eines Programms gebunden. Spezifische Datensicht für verschiedene Benutzer. Der Benutzer muss nach Form und Menge nur den ihn betreffenden Ausschnitt der Datenbank sehen. Die angegebenen Eigenschaften sind Zielvorstellungen und in der Praxis nicht in jedem Datenbank- Managementsystem realisiert. Bemerkung 1.1 [Datenbankadministrator] Die Betreuung des zentralen Datensystems benötigt eine spezielle, qualifizierte Dienstleistung. Mit dieser Aufgabe ist der Datenbankadministrator (DBA) beauftragt. 1.4 Die Architektur von Datenbanksystemen Im Jahre 1975 veröffentlichte das American National Standard Institut (ANSI) eine Studie bezüglich der Architektur eines Datenbanksystems. Das vorgeschlagene Konzept ist unter dem Namen 3-Schemen-Architektur bekannt und ist in der Abbildung 1-3 vereinfacht dargestellt. DBMS EDS (View) EDS (View) EDS (View) Externe Ebene LDS Logische Ebene Die Welt (Realität) PDS Interne Ebene (Physische Ebene) Speichermedium Abbildung 1-3: Die 3-Ebenen-Architektur Das vorgeschlagene Konzept sieht vor, in einem Datenbanksystem drei Ebenen mit unterschiedlichen Aufgaben zu unterstützen. Die Aufgaben der 3 Ebenen sind in der folgenden Liste erklärt. 1-4

7 Logische Ebene Auf dieser Ebene wird eine möglichst umfassende logische (das heisst, hardware- und applikationsunabhängige) Datenstruktur (in Abb. 1-3 LDS genannt) festgehalten. Angestrebt wird die Schaffung eines zentralen stabilen Bezugpunktes, der nur dann geändert werden muss, wenn der bislang betrachtete Realitätsausschnitt erweitert oder modifiziert wird. Über die auf dieser Ebene einzusetzende Strukturart sind nach wie vor Kontroversen im Gange. Allerdings scheint sich das auf präzisen, mathematisch fundierten Grundlagen basierende Relationenmodell mehr und mehr durchzusetzen. Das Relationenmodell wird im Kapitel 3 behandelt. Prinzipiell wären aber auf dieser Stufe auch hierarchische- Netzwerk oder objektorientierte Modelle. möglich. Interne Ebene Auf dieser Ebene ist mit einer sogenannten physischen Datenstruktur (PDS) festzuhalten, wie die Daten auf einem externen Speichermedium zu speichern sind. Die physische Datenstruktur wird unter Berücksichtigung der aktuellen Hardwaregegebenheiten von der konzeptionellen Datenstruktur abgeleitet. Die auf dieser Ebene eingesetzten Strukturarten sind Files, B-Trees, Hashtabellen usw. Externe Ebene Auf dieser Ebene ist mit Hilfe von sogenannten externen Datenstrukturen (EDS, auch Views genannt) festzuhalten, wie die Daten einem Benützer der Datenbank (damit sind sowohl Informatiker wie auch Endbenützer gemeint) zu präsentieren sind. Auch die externen Datenstrukturen sind diesmal allerdings unter Berücksichtigung der applikatorischen Anforderungen von der konzeptionellen Datenstruktur abzuleiten. Die auf dieser Ebene eingesetzten Werkzeuge sind sehr vielfältig und reichen von den konventionellen Datenstrukturen einer Programmiersprache über die interaktive Sprache SQL (Kapitel 5) bis zu 4GL-Tools. Bemerkung 1.2 [3-Schemen-Architektur] Es leuchtet ein, dass die 3-Schemen-Architektur, die im vorigen Abschnitt (1.2) geforderten charakteristischen Eigenschaften einer Datenbank gut unterstützt. 1.5 Physische Datenunabhängigkeit Im Abschnitt 1.3 haben wir die Datenunabhängigkeit schon erwähnt. Da diese Eigenschaft einer der wichtigsten Unterschiede zwischen einem Filesystem und einem Datenbanksystem darstellt, wird es an dieser Stelle noch einmal genauer erläutert. Vor allem sollen die Vorteile von datenunabhägigen Applikationen gegenüber datenabhängigen Applikationen (die mit Hilfe eines Filesystems implementiert sind) hervorgehoben werden. In einer datenabhängigen Applikation, sind Organisation und Zugriff auf die Daten in der Logik der Programme eingebaut. Dies wollen wir am folgenden Beispiel erläutern. Beispiel 1.1 [Filesystem] Wir nehmen an, der Kundenfile einer Firma enthalte als Felder (unter anderem) den Namen und den Umsatz des Kunden. Wir nehmen ferner an, dass über das Feld Name einen B-Tree existiert. Will man nun den Kunden Meyer suchen, so wird man die Tatsache ausnutzen, dass über das Feld Name ein B-Tree existiert und ein Befehl der Form get from KUNDE key = Meyer with index NAME; 1-5

8 schreiben. Wird nun der Kundenfile physisch reorganisiert und dabei der B-Tree über den Namen fallengelassen, so muss der obige Code entsprechend angepasst werden. Dieser Code ist also nicht datenunabhängig. Eine weitere Aufgabe ist das Auslisten aller Kunden mit einem Umsatz, der zwischen zwei gegebenen Zahlen Z1 und Z2 liegt. Die Kunden sollen nach Umsatz sortiert ausgegeben werden. Der folgende Pseudocode löst diese Aufgabe in einem Filesystem. getfirst from KUNDE; while (EOF == false) { if (Umsatz >= Z1 && Umsatz <= Z2) write to TEMP; getnext from KUNDE; } sort TEMP; getfirst from TEMP; while (EOF == false) { print(info); getnext from TEMP; } Das Problem im Beispiel 1.1 ist, dass die Applikation entscheidet, über welche Zugriffswege die Daten eingelesen werden. Damit eine Applikation datenunabhängig wird, muss die Applikation nur noch sagen welche Daten gebraucht werden. Der Zugriffsweg und das Lesen der Daten ist dann Sache des DBMS. Beispiel 1.2 [Datenbank] Wir wollen in diesem Beispiel zeigen, wie die Aufgaben aus dem Beispiel 1.1 mit Hilfe eines DBMS gelöst werden. Zugriff auf einen Kunden. select * from KUNDE where Name = Meyer ; Im Unterschied zu vorher wird nicht angegeben, welcher B-Tree verwendet wird. Dieser Entscheid wird vom Query-Optimizer des DBMS getroffen. Der Code Funktioniert unabhängig davon, ob ein B-Tree über den Namen existiert oder nicht. Umsatzliste: select from KUNDE where Umsatz >= Z1 and Umsatz <= Z2 order by Umsatz; loop (ueber alle gefundenen Kunden) print (info); Auch hier wird das DBMS entscheiden, wie die Kundensätze gefunden werden sollen (durch sequentielles Suchen und Sortieren oder über einen B-Tree). Man sieht sofort den Vorteil. Will man die Verarbeitung verschnellern, so kann ein B-Tree über das Feld Umsatz gelegt werden. Die Applikation selbst muss nicht verändert werden. 1-6

9 1.6 Der Datenbank Administrator (DBA) Verantwortlich für die logische und physische Organisation der Daten in einer Datenbank ist der Datenbankadministrator (DBA). Diese schwierige Aufgabe kann bei grossen Datenbeständen und vielen verschiedenen Benutzern nur mit Hilfe von guten Statistik- und Optimierungswerkzeugen gelöst werden. Solche Werkzeuge sind so wichtig, dass sie im DBMS integriert sein sollten. 1-7

10 1-8

11 Kapitel 2 Das Entity-Relationship Modell In diesem Abschnitt wollen wir uns mit dem konzeptionellen Datenbankentwurf befassen. Es geht darum, die Realität zu abstrahieren (d.h. vereinfachen) und nur die für unsere Zwecke wichtigen Aspekte in einem konzeptionellen Datenmodell festzuhalten. Ein konzeptionelles Datenmodell muss Hard- und Softwareunabhängig sein und für die Entwickler sowie für die zukünftigen Anwender eines Systems verständlich sein. Das von Chen 1976 in [Che76] eingeführte Entity-Relationship-Modell erfüllt genau diese Anforderungen. Es wurde speziell zum Design von relationalen Datenbanken entwickelt. Bemerkung 2.1 [Datenarchitektur] Das ERM eignet sich besonders gut zum Erstellen von globalen Datenarchitekturen. Das sind Modelle, die nur die Objekte und die Beziehungen zwischen diesen Objekten darstellen. Die Details der einzelnen Objekte werden zunächst weggelassen und erst im Verlauf der Applikationsentwicklung in der globalen Architektur ergänzt (top-down). 2.1 Datenmodellierung Wir wenden uns nun dem Problem der Datenmodellierung mit Hilfe des E-R-Modelles zu. Dieser Prozess findet auf einer möglichst hohen Abstraktionsstufe (d.h. Soft- und Hardwareunabhängig) statt und soll uns helfen, einen Ausschnitt der Realität zu modellieren und auch für Nichtinformatiker verständlich darzustellen. Es ist klar, dass jedes Modell nur einen Teil (oder gewisse Aspekte) der Realität wiedergeben kann. Daher ist die Wahl des Modells natürlich auch von der Art des Problems abhängig, das man lösen will. Ein allgemein gültiges Modell existiert nicht. Das E-R-Modell gibt es in sehr vielen Variationen. Die Grundideen sind aber im wesentlichen immer dieselben. Daher spielt es keine grosse Rolle, welche Beschreibung und vor allem welche Darstellungsart gewählt wird. In den folgenden Abschnitten wird das E-R-Modell vorgestellt. Es wird gezeigt, wie man mit Hilfe von einfachen Konstruktionselementen die Realität in einer dem menschlichen Verständnis entgegenkommende Weise abbilden kann. Zur visualisierung des Modells gibt es sehr viele verschidene Schreibweisen. Da die heutige Software heute meistens mit Hilfe von Klassendiagrammen beschrieben wird, werden wir diese Notation verwenden. 2-1

12 2.2 Darstellung von Einzelfällen Als Beispiel betrachten wir in den folgenden Ausführungen das Informationssystem für ein Spital. Wir werden an Hand dieses Beispiels die folgenden Konstruktionselemente darstellen: Entität, Eigenschaft, Faktum und Beziehung Entität Entitäten repräsentieren die für ein Informationssystem relevanten Informationsobjekte. Definition 2.1 [Entität] Eine Entität ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt, für welches applikationsbezogene Informationen von Bedeutung sind. Eine Entität kann also sein: Ein Individuum wie beispielsweise ein Arzt, ein Patient, eine Krankenschwester usw. Ein reales Objekt wie beispielsweise ein Operationssaal, ein Krankenzimmer usw. Ein abstraktes Konzept wie beispielsweise eine Diagnose, ein Fachgebiet usw. Ein Ereignis wie beispielsweise ein Kreislaufkollaps, eine Patientenaufnahme usw. Aus der Sicht des Modellentwerfers kann eine Entität folgendermassen charakterisiert werden: Eine eindeutig identifizierbare Einheit. Eine Einheit, deren Existenz auf einem geeigneten Speichermedium aufgrund eines Identifikationsmerkmal darstellbar sein muss (Schlüssel). Eine Einheit, für die Informationen zu sammeln und auf einem geeigneten Speichermedium festzuhalten sind. Diese Merkmale sind bei der Ermittlung der Ankerpunkte eines Datenmodells von entscheidender Bedeutung. 2-2

13 2.2.2 Eigenschaften Definition 2.2 [Eigenschaft] Eine Eigenschaft wird Entitäten zugeordnet und ermöglicht damit deren Charakterisierung Klassierung (vergleiche Abschnitt 2.3) Identifizierung (Schlüsseleigenschaften). Eine Eigenschaft besteht aus einem Namen und einer Menge von Eigenschaftswerten. Das nächste Beispiel zeigt für einen Arzt und einen Patienten mögliche Eigenschaften und Eigenschaftswerte. Beispiel 2.1 [Arzt Patient] Entität Eigenschaft Eigenschaftswert ein Patient Name Bachmann Alter 33 Gewicht 62 Sprachen {Deutsch Englisch Französisch} ein Arzt Name Meier Fachgebiet Innere Medizin Faktum Wird einer Entität eine Eigenschaft mit einem Eigenschaftswert zugeordnet, so kommt ein Faktum zustande. Definition 2.3 [Faktum] Ein Faktum ist eine Behauptung, derzufolge eine Entität für eine Eigenschaft einen bestimmten Eigenschaftswert aufweist. Die im Beispiel 2.1 für den Patienten festgehaltenen Eigenschaften und Werte bedeuten auf die Realität bezogen, dass der Patient Bachmann heisst, 33 Jahre alt ist, ein Gewicht von 62 kp aufweist und die Sprachen Deutsch, Englisch und Französisch spricht. Bemerkung 2.2 [unterschiedliche Fakten] Man beachte, dass ein und derselbe Eigenschaftswert durchaus mehreren Entitäten zugeordnet werden kann, wodurch entsprechend viele unterschiedliche Fakten zustande kommen Beziehung An einer Beziehung sind zwei oder mehr Entitäten beteiligt. Definition 2.4 [Beziehung] Eine Beziehung assoziert wechselseitig zwei (oder mehr) Entitäten. 2-3

14 In unserem Beispiel gibt es die Beziehung Arzt behandelt Patient und umgekehrt natürlich auch Patient wird von Arzt behandelt. Diese Beziehungen können wir formal folgendermassen festhalten: behandelt: < Arzt, Patient > und wird behandelt: < Patient, Arzt > Berücksichtigen wir dazu auch noch das Behandlungszimmer, so kommt eine Beziehung zwischen drei Entitäten zustande. Arzt behandelt Patient im Zimmer. Formal: behandelt: < Arzt, Patient, Zimmer > Auch für ein Beziehungselement sind Fakten möglich. Wir können dem Beziehungselement < Arzt, Patient > die Eigenschaft Krankheit mit dem Wert Angina zuweisen. Dieses neue Faktum bedeutet, dass ein bestimmter Arzt für einen bestimmten Patienten eine Angina diagnostiziert hat. 2.3 Darstellung von mehreren Fällen Die Abbildung der Realität nur mit Einzelfällen wäre ausserordentlich mühsam. Daher werden wir in diesem Abschnitt Konstruktionselemente vorstellen, die stellvertretend für viele Einzelfälle in Erscheinung treten können. Das heisst, wir führen eine neue Abstraktionsebene ein. Mit den bisherigen Konstruktionselementen können wir Aussagen der Art Der Arzt Meier behandelt den Patienten Bachmann machen. Mit den neuen Konstruktionselementen werden abstrakte und kompakte, dennoch auch für Nichtinformatiker verständliche Datenmodelle definierbar. Mit ihnen können allgemein gültige Aussagen der Art Ein Arzt hat einen Namen und behandelt mehrere Patienten, die auch einen Namen haben formuliert werden. Die Konstruktionselemente, die stellvertretend für mehrere Einzelfälle stehen, sind: Die Entitätsmenge Die Domäne (auch Wertebereich genannt) Das Entitätsattribut Die Beziehungsmenge Das Beziehungsattribut Die Entsprechung der Konstruktionselemente für Einzelfälle und denjenigen für mehrere Fälle sind in der Abbildung 2-1 dargestellt. 2-4

15 Entitaeten Konstruktionselemente zur Darstellung von Einzelfaellen Eigenschaften/ Werte Fakten Beziehungen Entsprechungen Entitaetsmengen Domaenen Attribute Beziehungsmengen Konstruktionselemente zur Darstellung von mehreren Faellen Abbildung 2-1: Entsprechung Einzelfall mehrere Einzelfälle Die Entitätsmenge Als erstes wollen wir den Typ einer Entität definieren. Definition 2.5 [Entitätstyp] Die Menge aller Eigenschaften, die eine Entität charakterisiert, nennt man den Typ der Entität. Mit Hilfe des Typs einer Entität können wir nun die Entitätsmenge definieren. Definition 2.6 [Entitätsmenge] Eine eindeutig benannte Menge von Entitäten des gleichen Typs nennt man Entitätsmenge Eine Entitätsmenge wird also aufgrund von Eigenschaften und nicht aufgrund von Eigenschaftswerten charakterisiert. Im Spitalbeispiel werden alle Patienten aufgrund der gleichen Eigenschaften wie Name, Alter und Gewicht charakterisiert und können demzufolge als Entitätsmenge namens Patient aufgefasst werden. Desgleichen werden alle Ärzte in eine Entitätsmenge Arzt zusammengefasst. Aus dem Arzt-Patienten-Beispiel geht sofort hervor, dass Entitätsmengen überlappen können. Es ist denkbar, dass ein Arzt zugleich auch Patient sein kann. Um diese Tatsache im Modell festzuhalten, führt man eine neue Entitätsmenge Person ein, welche sowohl Patienten wie auch Ärzte umfasst. Man spricht in diesem Zusammenhang von Überlagerung von Entitätsmengen, die wir im Abschnitt noch näher beschreiben werden. Mit der neuen Entitätsmenge Person lässt sich verhindern, dass ein bestimmtes Faktum (z.b. der Name einer Person) redundant festgehalten wird (beispielsweise für eine Person als Arzt und für die gleiche Person als Patient). Am Arzt-Patienten-Beisiel lassen sich auch die Begriffe unabhängige Entität (oder Kernentität) und abhängige Entität erklären. In unserem Beispiel können Informationen für einen Arzt nur dann spezifiziert werden, wenn besagter Arzt auch als Person bekannt ist. Dasselbe gilt natürlich auch für Patienten. In diesem Beispiel sind Personen Kernentitäten, Ärzte und Patienten abhängige Entitäten. Definition 2.7 [Kernentität] Eine Kernentität ist eine Entität, deren Existenz unabhängig anderweitiger Entitäten ist. 2-5

16 Bei der Realitätsmodellierung sind Entitätsmengen von Kernentitäten wir nennen diese im folgenden Kernentitätsmengen die eigentlichen Modellaufhänger (oder Ankerpunkte). Die Anzahl der Kernentitätsmengen ist beschränkt und wird auch bei komplexen Datenmodellen kaum mehr als zehn betragen. Im Unterschied zu einer Kernentität, die immer eigenständig in Erscheinung tritt, ist die Existenz einer abhängigen Entität immer von etwas anderem abhängig und kann wie folgt definiert werden: Definition 2.8 [abhängige Entität] Eine abhängige Entität ist eine Entität, deren Existenz von einer anderweitigen Entität (Kern- oder abhängige Entität) abhängig ist Domäne oder Wertebereich Definition 2.9 [Domäne] Eine Domäne legt eine eindeutig benannte Kollektion (Menge) der zulässigen Eigenschaftswerte einer Eigenschaft fest. Durch Angabe der Domäne werden also die möglichen Werte einer Eigenschaft eingeschränkt. Man kann Domänen auch als Integritätsbedingungen auffassen. Die Domäne einer Eigenschaft E bezeichnen wir mit dom(e). Beispiel 2.2 [Domäne] Wir wollen hier einige Beispiele für Domänen angeben: dom(name): Alle Folgen von maximal 20 Buchstaben, wobei der erste Buchstabe gross, die anderen klein geschrieben sind. dom(gewicht): 0 Gewicht 150 dom(sprache): {Deutsch, Französisch, Englisch} Entitätsattribut Wir erinnern uns, dass ein Faktum die Behauptung darstellt, dass eine Entität für eine Eigenschaft einen bestimmten Eigenschaftswert aufweist. Wir übertragen nun diesen Begriff auf alle Elemente einer Entitätsmenge Definition 2.10 [Entitätsattribut] Ein Entitätsattribut assoziert die Entitäten einer Entitätsmenge mit Eigenschaftswerten, die einer (oder mehreren) Domäne(n) angehören. Im folgenden wird gezeigt, dass einem Entitätsattribut verschiedene Kardinalitäten zugrunde liegen können. Wir unterscheiden in unserem Datenmodell vier solche Kardinalitäten: Einfache (Typ 1) Kardinalität Konditionelle (Typ C) Kardinalität Komplexe (Typ M) Kardinalität Komplex-Konditionelle (Typ MC) Kardinalität Diese vier Typen werden im folgenden vorgestellt. 2-6

17 Einfache oder Typ 1 Kardinalität Eine Person weist (normalerweise) zu jedem Zeitpunkt genau einen Namen auf. In diesem Fall liegt eine einfache (oder Typ 1) Kardinalität von der Menge Person zur Menge dom(name) vor. Definition 2.11 [Einfache Kardinalität] Eine einfache (Typ 1) Kardinalität N von einer Menge A zu einer Menge B bedeutet, dass jedes Element in A jederzeit mit einem Element in B in Beziehung steht. In der Mathematik nennt man eine solche Kardinalität eine Funktion. Formal schreiben wir: N : A B Also in unserem Beispiel könnte man Name: Person dom(name) schreiben Konditionelle oder Typ C Kardinalität In unserem Beispiel soll jeder Patient Mitglied höchstens einer Krankenkasse sein, möglicherweise aber auch nicht versichert sein. In diesem Fall liegt eine konditionelle (oder Typ C) Kardinalität von der Menge Patient zur Menge dom(krankenkasse) vor. Definition 2.12 [konditionelle Kardinalität] Eine konditionelle (Typ C) Kardinalität N von einer Menge A zu einer Menge B bedeutet, dass jedes Element in A höchstens mit einem, möglicherweise mit keinem Element in B in Beziehung steht. In der Mathematik nennt man eine solche Kardinalität eine partielle Funktion. Formal schreiben wir: N : A B In unserem Beispiel würden wir also schreiben. Krankenkasse: Patient dom(krankenkasse) Komplexe oder Typ M Kardinalität Eine Person kennt mindestens ihre Muttersprache. Möglicherweise hat diese Person aber auch Kenntnisse in mehreren anderen Sprachen. In diesem Fall liegt eine komplexe (oder Typ M) Kardinalität von der Menge Person in die Menge dom(sprache) vor. 2-7

18 Definition 2.13 [komplexe Kardinalität] Eine komplexe (Typ M) Kardinalität N von einer Menge A zu einer Menge B bedeutet, dass jedes Element in A mindestens mit einem, möglicherweise mit mehreren Elementen in B in Beziehung steht. Mathematisch gesehen ist das eine Funktion von der Menge A in die Potenzmenge von B (ohne leere Menge). Formal schreiben wir: N : A P(B) \ {} In unserem Beispiel würden wir also schreiben. Sprachen: Person P(dom(Sprache))\{} Komplex-konditionelle oder Typ MC Kardinalität In unserem Beispiel kann ein Arzt kein, ein oder mehrere Spezialgebiete haben. In diesem Fall liegt eine komplex-konditionelle (oder Typ MC) Kardinalität von der Menge Arzt in die Menge Spezialgebiet vor. Definition 2.14 [komplex-konditionelle Kardinalität] Eine komplex-konditionelle (Typ MC) Kardinalität N von einer Menge A zu einer Menge B bedeutet, dass jedes Element in A mit beliebig vielen (also auch null oder nur einem) Elementen in B in Beziehung stehen kann. Mathematisch gesehen ist das eine Funktion von der Menge A in die Potenzmenge von B. Formal schreiben wir: N : A P(B) In unserem Beispiel würden wir also schreiben. Spezialgebiet: Arzt P(dom(Spezialgebiet)) Bemerkung 2.3 [Kardinalität und Beziehungsmengen] Dem Begriff Kardinalität werden wir im Abschnitt noch einmal begegenen, wenn es darum geht die Beziehungen zwischen Entitätsmengen zu charakterisieren Entitätsschlüssel Wir erinnern uns, dass eine Entität nach Definition eindeutig identifizierbar sein muss. Der Identifikator einer Entität nennt man Entitätsschlüssel. Definition 2.15 [Entitätsschlüssel] Ein Entitätsschlüssel ist ein Entitätsattribut, mit dessen Werten die Entitäten einer Entitätsmenge eindeutig zu identifizieren sind. 2-8

19 Weil mit natürlichen Attributen wie Name oder Wohnort usw. in der Regel keine eindeutige Identifikationen zu erzielen ist, legt man einem Entitätsschlüssel normalerweise ein künstliches Attribut wie p_nr (Personalnummer) zugrunde. Dieses Attribut muss gemäss Zehnder [Zeh89] folgenden Kriterien genügen: Der Schlüsselwert ist eindeutig und unveränderlich. Eine neuauftretende Entität erhält ihren Schlüsselwert sofort. Bemerkung 2.4 [Zusammengesetzter Schlüssel] Der Schlüssel kann im Prinzip auch aus mehreren Attributen bestehen. In diesem Fall spricht man auch von einem zusammengesetzten Schlüssel Darstellung von Entitätsmengen und Entitätsattribute Entitätsmengen werden in unserem graphischen Modell mit dem Klassensymbol (Rechteck) dargestellt. Das Rechteck wird mit dem Namen der Entitätsmenge beschriftet. Zusätzlich wird mit dem Stereotyp <<entity>> angegeben, dass es sich um eine persitente Entitätsmenge und nicht um eine transiente Klasse handelt. Entitätsattribute können direkt innerhalb des Rechtecks für die Entitätsmenge angegeben werden. Der Entitätsschlüssel wird mittels einer Constraint angegeben. Die graphische Darstellung ist in der Abbildung 2-2 angegeben. <<entity>> Patient p_nr name alter krankenkasse [0..1] sprachkenntnisse [1..*] allergie [0..*] {Entitykey} Abbildung 2-2: Darstellung von Entitätsmengen und Attributen Die Spezifikation für die Attribute ist folgendermassen gegeben: Attribut ::= name [: type-expression] [multiplicity] name ::= Name des Attributs type-expression := Ein primitiver UML Datentyp (Integer, Boolean oder String) oder ein Datenbanktyp. Letztere sind natürlich von der gewählten Datenbank abhängig. multiplicity ::= lower-bound..upper-bound. lower und upper-bound sind ganze Zahlen und geben an wieviele Elemente minimal und maximal zugelassen werden. upper-bound kann durch * ersetzt werden. Dies bedeutet beliebig viele. Falls keine multiplicity angegeben ist, wird 1..1 angenommen. Beispiele: name geburtsdatum : date sprache [0..*] : string Nur der Name des Attributs Mit Datentyp Mehrwertigkeit Die Kardinalitäten 1, C, M und MC können folgendermassen dargestellt werden: 2-9

20 name Kardinalitätstyp 1 krankenkasse[0..1] Kardinalitätstyp C sprachkenntnisse[1..*] Kardinalitätstyp M allergie[0..*] Kardinalitätstyp MC Beziehungsmengen Als erstes wollen wir den Beziehungstyp definieren und mit Hilfe dieses Begriffs die Beziehungsmenge. Definition 2.16 [Beziehungstyp] Beziehungen, an denen jeweils Entitäten der gleichen Entitätsmengen beteiligt sind, sind vom gleichen Beziehungstyp, sofern sie allesamt ein und dieselbe Beziehungsart betreffen. Wir wollen noch an Hand von zwei Beispielen zeigen, was unter einer Beziehungsart gemeint ist: 1. Welche Ärzte behandeln welchen Patienten? 2. Welche Studenten besuchen welche Vorlesungen? Wir können nun den Begriff der Beziehungsmenge definieren. Definition 2.17 [Beziehungsmenge] Eine Beziehungsmenge ist eine eindeutig benannte Kollektion von Beziehungselementen gleichen Beziehungstyps. Beispiel 2.3 [Arzt behandelt Patient] In unserem Arzt-Patienten-Beispiel können wir alle Beziehungen der Art Arzt behandelt Patient in einer Beziehungsmenge behandelt zusammenfassen. Diese Menge zeigt, welcher Arzt welchen Patienten behandelt. Umgekehrt ist natürlich auch festgehalten von welchen Ärzten ein Patient behandelt wird Kardinalität Wie im obigen Beispiel gesehen bestehen zwischen Entitätsmengen und Beziehungsmengen auch Kardinalitäten. Zwischen der Entitätsmenge Arzt und der Beziehungsmenge behandelt besteht eine Typ M Beziehung. Im Prinzip sind dieselben Kardinalitätstypen zwischen Entitätsmengen und Beziehungsmengen möglich wie zwischen Entitätsmengen und den Domänen von Attributen Um die Kardinalität darzustellen verwenden wir die sogenannte MC- Darstellung. Wir können in unserem Beispiel die Beziehung zwischen Arzt un Patient folgendermassen aufschreiben: Das heisst, von links nach rechts gelesen: behandelt: Arzt 1:M Patient oder von rechts nach links: Ein Arzt behandelt ein oder mehrere Patienten (Typ M) Ein Patient wird von genau einem Arzt behandelt (Typ 1). 2-10

21 Beziehungsmenge als Entitätsmenge Beziehungsmengen können auch als spezielle Entitäten aufgefasst werden. Dies hat den Vorteil, dass Beziehungsmengen von Entitäten überlagert werden können. Ferner wird es auch möglich, dass eine Beziehungsmenge Beziehungsattribute besitzt (siehe 2.3) Rekursive Beziehungen Ein anderer Fall, wo Beziehungsmengen wichtig sind, ist wenn nur eine Entitätsmenge beteiligt ist. In diesem Fall entstehen rekursive Strukturen. Im folgenden Beispiel wollen wir das Stücklistenproblem behandeln. Beispiel 2.4 [Stückliste] Gegeben sei eine Entitätsmenge Produkt, die die Produkte (Entitäten) p 1, p 2, p 3,... enthalte. In der Regel setzt sich ein einzelnes Produkt aus mehreren anderweitigen Produkten zusammen. Man nennt eine Operation, welche die für die Herstellung eines Produktes erforderlichen Komponenten bestimmt, eine Auflösung. Offensichtlich stehen die Entitäten der Entitätsmenge Produkt aufgrund einer Auflösungsbeziehung komplexkonditionell (Typ MC) mit Entitäten der gleichen Entitätsmenge in Beziehung. Um dies darzustellen führen wir die Beziehungsmenge verwendet ein und schreiben: Gelesen: verwendet: Produkt MC:MC Produkt Ein Produkt verwendet kein, ein oder mehrere weitere Produkte. Ein Verwendungsnachweis ist eine Operation, die es erlaubt, jene Produkte zu finden, deren Herstellung eine bestimmte Komponente benötigen. Diese Beziehung ist aber gerade die zur Auflösungsbeziehung inverse Beziehung. Das heisst, wir können dieselbe Beziehungsmenge verwendet benutzen und einfach von rechts nach links lesen: Ein Produkt wird in keinem, einem oder mehreren Produkten verwendet Die Beziehungselemente der Menge verwendet bestehen aus geordneen Paaren. Das erste Element ist das herzustellende Produkt, das zweite Element ist ein für die Herstellung erforderliches Produkt. Wir nehmen an, dass die Herstellung des Produktes p 1 die Produkte p 2, p 3 und p 4 benötigt. In diesem Fall werden die Beziehungselemente < p 1, p 2 > < p 1, p 3 > < p 1, p 4 > zur Beziehungsmenge verwendet gehören. 2-11

22 2.3.7 Darstellung von Beziehungsmengen In unserem Modell werden Beziehungsmengen als ausgezogene Linien dargestellt. Die Kardinalitäten werden mit der m... n Notation angegeben Mit Hilfe von Beziehungsmengen können alle Beziehungsarten (1:1, C:1, M:1 usw.) zwischen Entitäten dargestellt werden. In der Abbildung 2-3 ist eine M zu M (a) eine 1 zu M (b) und eine 1 zu MC Beziehung zwischen Ärzten und Patienten dargestellt. Alle anderen Beziehungsarten werden analog dargestellt. <<entity>> Arzt 1..* behandelt 1..* <<entity>> Patient a) Ein Arzt behandelt mehrere Patienten und ein Patient wird von mehreren Aerzten behandelt. <<entity>> Arzt 1 behandelt 1..* <<entity>> Patient b) Ein Arzt behandelt mehrere Patienten und ein Patient wird von genau einem Arzt behandelt. <<entity>> Arzt 1 behandelt 0..* <<entity>> Patient c) Ein Arzt behandelt kein, ein oder mehrere Patienten, ein Patient wird von einem Arzt behandelt. Abbildung 2-3: Darstellung von Beziehungsmengen (M:M und M:1) Bemerkung 2.5 [Lesen der Beziehung] Der ausgefüllte Pfeil beim Namen der Beziehungsmenge gibt an, in welcher Richtung gelesen werden muss. In userem Fall also Arzt behandelt Patient Beziehungsattribut Das Prinzip eines Beziehungsattributes ist mit jenem eines Entitätsattributes vergleichbar. Wir erinnern uns, dass eine Beziehungsmenge auch als spezielle (abhängige) Entitätsmenge angesehen werden kann. Definition 2.18 [Beziehungsattribut] Ein Beziehungsattribut assoziert die Beziehungselemente einer Beziehungsmenge mit Eigenschaftswerten, die einer (oder mehreren) Domäne(n) angehören. Bemerkung 2.6 [Kardinalität von Beziehungsattributen] Für Beziehungsattribute gelten dieselben Kardinalitäten wie für Entitätsattribute. Das heisst, einfache (Typ 1), konditionelle (Typ C) und komplexe (Typ M) Kardinalität. Beispiel 2.5 [Anteil in Stückliste] Als Beispiel betrachten wir wieder das Stücklistenproblem. Wir wollen in unserem Modell nun eine weitere Information einfügen, die angibt, wieviele Komponenten eines Typs zur Herstellung eines bestimmten Produktes nötig sind. Es ist sofort ersichtlich, dass dies nicht eine Eigenschaft des Produktes ist, sondern die Eigenschaft einer Beziehung zwischen zwei Produkten. Wir führen daher das Beziehungsattribut Anzahl mit der Domäne Ganze-Zahl ein. 2-12

23 2.3.9 Darstellung von Beziehungsattributen Falls vorhanden werden Beziehungsattribute, wie in der Abbildung 2-4 angegeben als Entitätsmengen dargestellt. <<entity>> Arzt 1..* behandelt 1..* <<entity>> Patient <<entity>> ArztPatient Diagnose Abbildung 2-4: Beziehungsattribut 2.4 Semantische Datenmodellierung Das ER-Modell nach Chen wurde von verschiedenen Autoren zur semantischen Datenmodellierung erweitert. Wichtige zusätzliche Konzepte sind die Aggregation und die Generalisierungshierarchie Generalisierung Wir haben im Abschnitt an Hand des Arzt-Patienten-Beispiels gesehen, wie mit Hilfe der Überlagerung Redundanz vermieden werden kann. Mit der Überlagerung von Entitätsmengen können wir das Konzept der stufenweise Spezialisierung und Generalisierung von Informationen realisieren. Beispiel 2.6 [Person als Generalisierung] Im Arzt-Patienten-Beispiel ist die Entitätsmenge Person eine Generalisierung von Arzt und Patient. Umgekehrt sind Patient und Arzt Spezialisierungen von Person. Mit der Generalisierung und der Spezialisierung können wir unter den Entitätsmengen eine Hierarchie einführen. Wir können dann von Vorgängern und Nachfolgern einer Entitätsmenge sprechen. Im objektorientierten Ansatz spricht man von einer Is-a-Hierarchie (ist ein). Zum Beispiel kann man sagen: Ein Arzt ist eine Person. Person ist in diesem Fall die allgemeinere Entität (Generalisierung), der Arzt die speziellere Entität (Spezialisierung). Ferner ist klar, dass ein Arzt nur existieren kann, wenn er als Person existiert. Daher ist Person eine Kernentität und Arzt eine abhängige Entität Möglichkeiten bei der Generalisierung Bei der Generalisierung zweier Entitätsmengen zu einer neuen Entitätsmenge können vier verschiedene Fälle resultieren. Diese Fälle wollen wir nachfolgend an Hand von Beispielen betrachten. 1. Eine Person ist entweder eine Frau oder ein Mann. Frau und Mann sind disjunkt und überlagern Person vollständig. 2-13

24 2. Die Mengen der Krankenzimmer und der Operationssäle sind disjunkt, aber es gibt im Spital noch weitere Räume wie Untersuchungszimmer, Büros usw. 3. In einem Spital gehört jede relevante Person entweder zum Personal oder ist ein Patient. Wie wir aber schon gesehen haben kann ein Angestellter auch gleichzeitig Patient sein. 4. Dass ein Patient auch Arzt sein kann, haben wir schon gesehen. In einem Spital kann es aber auch weitere Personen wie Krankenschwestern, Reinigungspersonal usw. geben Darstellung von Generalisierungen Die Genaralisierung wird mit Hilfe eines Pfeiles dargestellt Die verschiedenen Möglichkeiten, die im Abschnitt 2.3 gezeigt wurden, werden mit Hilfe von abstrakten Klassen und mit speziellen Constraints (overlapping oder disjunkt) dargestellt. Die graphischen Darstellungen für diese Fälle sind in der Abbildung 2-5 angegeben. <<entity>> Person <<entity>> Raum {disjoint} {disjoint} <<entity>> <<entity>> <<entity>> <<entity>> Frau Mann Operationssaal Krankenzimmer a) Frau und Mann sind disjunkt und ueberlagern b) Operationssaal und Krankenzimmer sind disjunkt Person vollstaendig. ueberlagern aber Raum nicht vollstaendig. <<entity>> Person <<entity>> Person {overlapping} {overlapping} <<entity>> Angestellter <<entity>> Patient <<entity>> Arzt <<entity>> Patient c) Angestellter und Patient sind nicht disjunkt und ueberlagern Person vollstaendig c) Angestellter und Patient sind nicht disjunkt ueberlagern Person aber nicht vollstaendig Abbildung 2-5: Darstellung der verschiedenen Überlagerungen 2-14

25 2.4.3 Aggregation Werden mehrere Einzelobjekte (z. B. Patient und Spital) zu einem eigenständigen Einzelobjekt (z. B. Belegung) zusammengefasst, dann spricht man von Aggregation. Dabei wird das übergeordnet eigenständige Ganze (in userem Fall die Belegung) Aggregat genannt. Die Teile (in unserem Fall Spital und Patient), aus denen es sich zusammensetzt, heissen Komponenten. Aggregat und Komponenten werden als Entitätsmengen deklariert. Bei Aggregation/Zerlegung wird zwischen Rollen- und Mengenaggregation unterschieden. Eine Rollenaggregation liegt vor, wenn es mehrere rollenspezifische Komponenten gibt und diese zu einem Aggregat zusammengefasst werden. Beispiel 2.7 [Operaqtionsteam] Ein Operationsteam besteht aus Chirugen, einem Anästhesisten und Operationsschwestern. Das Operationsteam ist das Aggregat, die Personen sind die Komponenten, wobei die Personen in verschiedenen Rollen in Erscheinung treten. Eine Mengenaggregation liegt vor, wenn das Aggregat durch Zusammenfassung von Einzelobjekten aus genau einer Entitätsmenge entsteht. Beispiel 2.8 [Fussballmanschaft] Als Beispiel können wir eine Fussballmanschaft betrachten, die eben aus Fussballspieler besteht Darstellung von Aggregationen Die Agreggation wird als Beziehungen zwischen dem Ganzen und den entsprechenden Teilen angezeigt. Auf der Seite des Ganzen wird am Anfang der Beziehung noch eine Raute gezeichnet, die angibt, dass es sich um eine Aggregation handelt. In der Abbildung 2-6 ist ein Operationsteam als Aggregation dargestellt. besteht aus <<entity>> Operationsteam besteht aus 1..* 1..* <<entity>> Chirurg <<entity>> OpSchwester 1..* <<entity>> Anästhesist Abbildung 2-6: Darstellung der Aggregation Vorgehen In diesem Abschnitt werden die methodischen Konstruktionsschritte zur Entwicklung von konzeptionellen Datenmodellen dargestellt. Wir werden versuchen, wenn immer möglich, das Modell Top-Down zu entwickeln. Das heisst, von den Kernentitäten und deren Beziehungen bis hinunter zu den Attributen. Wir wollen das Vorgehen gerade an Hand des folgenden Beispiels präsentieren. Beispiel 2.9 [Kurssystem: Beschreibung] Gegeben seien die folgenden Realitätsbeobachtungen. 2-15

26 1. Eine Unternehmung organisiert firmeninterne Kurse unterschiedlichen Typs (z.b. Informatik, Betriebswirtschaftslehre usw.). Für jeden Kurstyp gibt es normalerweise jährlich mehrere Kursangebote. 2. Jedes Kursangebot erfordert einen Lehrer. Ein Lehrer ist in der Regel für mehrere Kursangebote zuständig. 3. Für jedes Kursangebot schreiben sich in der Regel mehrere Studenten ein. Ein Student kann sich für mehrere Kursangebote einschreiben. 4. Die Dozenten und Studenten sind alle Angestellte der Firma. Ein Angestellter kann sowohl als Dozent wie auch als Student tätig sein. 5. Jeder Kurs erfordert einen Klassenraum. Ein Klassenraum kann von verschiedenen Kursen belegt sein, falls diese nicht gleichzeitig stattfinden. 6. Kurse müssen in einer vorgegebenen Sequenz besucht werden. In der Regel können einem bestimmten Kurstyp mehrere anderweitige Kurstypen folgen. Umgekehrt erfordert ein bestimmter Kurstyp in der Regel vorgängig den Besuch von mehreren anderweitigen Kurstypen Erkennen von Entitätsmengen Die für die Aufgabe wesentlichen Entitätsmengen der Realität werden aufgrund einer reifenden Vorstellung des Entwicklers vom Problemraum deduktiv erkannt. Dieses ist ein grosser Schritt, der nur mit einiger Erfahrung im Anwendungsbereich und mit der aktiven Hilfe des Anwenders zuverlässig funktionieren kann. Die folgenden Ansatzpunkte für diese Aufgabe stammen aus [CY91]. Wo sollte man suchen? Im Problemraum, in textlichen und in graphischen Darstellungen. Im Gespräch mit den Anwendern des Systems. Wonach sollte man suchen? Struktur der Aufgabe, andere Systeme, über die Informationen gespeichert werden müssen, Ereignisse, an die man sich erinnern muss, Rollen, die von Individuen gespielt werden, Orte, an denen für das System Wichtiges passiert, Organisationseinheiten, denen Menschen angehören, oder die sonst wichtig sind. Was ist zu berücksichtigen? Braucht das System die Erinnerung an frühere Begebenheiten? 2-16

27 Muss das System auf Anforderungen von aussen Leistungen erbringen? Gibt es in der Entitätsmenge mehr als eine Entität? Gibt es mehr als ein Attribut? Gibt es in den Beschreibungen Synonyme und Homonyme? Welche Fehler kann man machen? Erinnerung speichern, die eigentlich nicht benötigt wird. Aufgaben oder Leistungen berücksichtigen, die niemals abgefordert werden. Entitätsmengen modellieren, die nur aus einem Element bestehen. Ergebnisse speichern, die aus anderen abgeleitet werden können. Aufgrund der Betrachtungen der Realität wird ein Entitäts-Kandidaten-Katalog aufgestellt. Pro Entitäts-Kandidat werden der Name der Entitätsmenge, falls nötig eine charakterisierende Beschreibung und eventuell typische Beispiele festgehalten. Beispiel 2.10 [Kurssystem: Mögliche Entitätsmengen des Systems] In unserer Beschreibung sind alle Substantive unterstrichen. Diese kommen als Kanditaten für Entitätsmengen in frage. Unternehmung, Kurs, Typ, Informatik, Betriebswirtschaftslehre, Kurstyp, Kursangebot, Lehrer, Student, Dozent, Angestellter, Firma, Klassenraum, Sequenz, Besuch. Als nächsten Schritt werden falls vorhanden Synonyme und Homonyme aus dem erstellten Katalog entfernt. Entwickler und Anwender müssen sich auf einen Begriff einigen. Diese Abmachungen sind dann für das ganze Projekt verbindlich. Nachfolgend noch die Definition von Synonymen und Homonymen. Definition 2.19 [Synonym] Als Synonyme bezeichnet man zwei Wörter derselben Sprache, welche dieselbe (oder fast dieselbe) Bedeutung haben. Zum Beispiel sind Samstag und Sonnabend Synonyme. Definition 2.20 [Homonym] Als Homonym bezeichnet man Wörter, die verschiedene Bedeutungen haben können. Zum Beispiel bezeichnet das Wort Tau sowohl eine Form von Niederschlag, ein Seil sowie der griechische Buchstabe τ. Beispiel 2.11 [Kurssystem: Synonyme und Homonyme] In unserem Beispiel können die folgenden Synonyme gefunden werden. Die für den weiteren Verlauf des Entwurfs festgelegten Begriffe sind fett gedruckt. Unternehmung Firma Kurs Kurstyp Typ Lehrer Dozent 2-17

28 Kurs Kursangebot Bemerkung 2.7 [Kurstyp und Kursangebot] Kurstyp und Kursangebot sind in dieser Lösung keine Synonyme. Kurstyp ist die Beschreibung eines Kurses (Inhalt, Voraussetzungen, Literatur usw.). Kursangebot hingegen bezeichnet die konkrete Durchführung eines Kures von einem bestimmten Typ. Im Kontext der Aufgabe wird Kurs sowohl für Kurstyp wie auch für Kursangebot verwendet und ist daher ein Homonym. Im Punkt 5 der Aufgabe wird Kurs für Kursangebot verwendet. Jeder Kurs erfordert einen Klassenraum. Im Punkt 6 der Aufgabe wird Kurs für Kurstyp verwendet. Kurse müssen in einer vorgegebenen Sequenz besucht werden. Nun muss entschieden werden, welche Entitäts-Kandidaten auch wirklich als Entitätsmengen aufgenommen werden. Entitäts-Kandidaten sind wahrscheinlich Entitätsmengen, wenn sie: Eine eigene Bedeutung haben, die das System unabhängig von seiner Implementierung beachten muss. Eigene Attribute haben. Wobei zu beachten ist, dass beim Modellieren einer Datenarchitektur die genauen Attribute zu diesem Zeitpunkt meistens noch nicht bekannt sind. In das abgegrenzte Gebiet hineingehören. Entitäts-Kandidaten sind sicher keine Entitätsmengen, wenn sie Berichte, Auswertungen oder Auskünfte sind. Diese sind Ergebnis von Funktionen und deshalb keine Entitätsmengen. Nur dem Inhalt nach Bedeutung haben, jedoch nicht als eigene Objekte (zum Beispiel Beziehungen, Aktionen oder Wertebeispiele für Attribute). Beispiel 2.12 [Kurssystem: Keine Entitätsmengen] Firma Besuch Informatik Betriebswirtschaftslehre Sequenz Zur Firma werden keine Daten gesammelt daher muss diese auch nicht als Entitätsmenge aufgenommen werden. Die Firma kann auch als das gesammte System angesehen werden. Drückt eine Beziehung zwischen Kursangebot und Student aus. Diese beiden Begriffe sind Eigenschaftswerte des Kurstyps und keine eigenen Entitäten. Sequenz ist eine Beziehung zwischen Kurstypen und keine Entitätsmenge. 2-18

29 Unter den gefundenen Entitätsmengen werden noch die Kernentitätsmengen gesucht. Dabei können die folgenden Kriterien angewandt werden. Sind die Kernentitäten nicht Speziallfälle einer generelleren Entitätsmenge? Sind die Kernentitätsmengen alle paarweise disjunkt? Sind die Kernentitäten nicht Bestandteil von Entitäten in einer anderen Entitätsmenge? Beispiel 2.13 [Kurssystem: Entitäten des Systems] Wir können nun den bereinigten Katalog der Entitätsmengen angeben und gleichzeitig die Kernentitäten bezeichnen. Entität Kern Begründung Angestellter Ja Existiert unabhängig vom System. Dozent Nein Muss ein Angestellter sein. Student Nein Muss ein Angestellter sein. Klassenraum Ja Existiert physisch und ist unabhängig vom System. Kurstyp Ja Kann unabhängig von allen andern Entitäten des Systems definiert werden. Kursangebot Nein Kann nur zu einem Kurstyp existieren Erkennen von Beziehungsmengen Alle Entitätsmengen werden nun paarweise gegenübergestellt und nach in der Realität existierenden Verknüpfungen untersucht. Auf diese Weise werden logische Abhängigkeiten erkannt. Für jeden erkannten Beziehungstyp wird festgehalten: Name der Beziehung. Die beteiligten Entitäten und die Kardinalitäten. Beispiel 2.14 [Kurssystem: Erkennen von Beziehungsmengen] Aus der Realitätsbeschreibung können wir folgende Beziehungen zwischen Entitäten feststellen: Aus Punkt 1 hat Typ: Kursangebot MC:1 Kurstyp Aus Punkt 2 doziert: Dozent 1:MC Kursangebot Aus Punkt 3 besucht: Student MC:MC Kursangebot Aus Punkt 4 ist: Dozent C:1 Angestellter ist: Student C:1 Angestellter Aus Punkt 5 braucht: Kursangebot MC:1 Klassenraum 2-19

30 Aus Punkt 6 folgt: Kurstyp MC:MC Kurstyp Semantische Datenmodellierung Aus den gefundenen Beziehungen, suchen wir nun nach möglichen Genralisierungen (bzw. Spezialisierungen) sowie nach Aggregationen. Beispiel 2.15 [Kurssystem: Generalisierung] Aus den Beziehungen zwischen Angestellter, Dozent und Student sieht man, dass Dozent und Student Spezialisierungen von Angestellter darstellen. Dozent und Student sind nicht disjunkt und überdecken Angestellter nicht vollständig Erkennen von Attributen Einige Entitätsattribute sind bereits bekannt, wenn die entsprechende Entitätsmenge identifiziert wird. In Rücksprachen mit dem Anwender und nach Auswertung der vom Anwender benutzten Formblätter, Karteikarten usw. werden weitere Attribute identifiziert. Auch hier ist die Erfahrung des Entwicklers gefordert. Folgende Punkte sind zu beachten: Jedes Attribut muss einen eindeutigen Namen besitzen. Der Wertebereich und die Kardinalität der Attribute müssen zweifelsfrei festgelegt werden. Attribute aus Vorgängersystemen dürfen nicht einfach unkritisch in das neue System übernommen werden. Man findet häufig Informationen, die gespeichert, aber nirgends benutzt werden. Bemerkung 2.8 [Definition der Attribute] Attribute können auch später bei der Entwicklung der Funktionen des Systems identifiziert werden. Ist die Datenarchitektur gut, so sollte es kein Problem darstellen, solche Attribute bei der richtigen Entitätsmenge einzuordnen. Beispiel 2.16 [Kurssystem: Erkennen von Attributen] Aus der Beschreibung des Systems lassen sich nicht viele Attribute eindeutig bestimmen. Nachfolgend eine (unvollständiger) Liste. Angestellter Klassenraum Kurstyp Kursangebot a_nr, name kr_nr, plaetze kt_nr, bezeichnung ka_nr, kurstag[1..*] : Date 2-20