Читать книгу Relationale Datenbanken - Josef Ludwig Staud - Страница 11

3 Konzeptionelle Modellierung

Hinweis: Nicht verwirren lassen. Seit einigen Jahren taucht in der Fachliteratur der Ausdruck "konzeptuelle Modellierung" statt "konzeptionelle Modellierung" auf. Dies ist wahrscheinlich vom englischen Fachbegriff "conceptual" her motiviert. Beide Begriffe bedeuten dasselbe.

Exkurs: Informationsträger

Für Objekte im hier gebrauchten Sinn wird in der angelsächsischen Literatur nicht der Begriff object, sondern der Begriff entity verwendet. Dieser bedeutet, betrachtet man den Sprachgebrauch, soviel wie Informationsträger im Sinne von: Alles was durch Informationen (hier im wesentlichen Attribute) beschrieben werden kann. Einige deutschsprachige Autoren verwenden für entity das Wort Entität.

3.1 Anwendungsbereiche

Am Anfang des Datenbankdesigns steht die Analyse des Anwendungsbereichs für den die Datenbank zu erstellen ist. Dieser wird meist Anwendungsbereich genannt. Z.B. die Abteilung Vertrieb eines Unternehmens. Oder ganze Unternehmen, wenn zum Beispiel für eine integrierte prozessorientierte Software (wie sie z.B. SAP herstellt) die Datenbank eingerichtet werden soll. Aber auch kleine Anwendungsbereiche sind denkbar. Z.B. wenn ein Unternehmen für seine Produkte versucht, den Absatz vorherzusagen und wenn dafür eine Datenbank eingerichtet wird. Und auch wenn man sich entschließt, die Filmesammlung in einer Datenbank zu verwalten und dafür Daten zu erfassen, stellt diese einen Anwendungsbereich dar.

Internet

Ganz besonders spannende und auch große Anwendungsbereiche finden sich im Internet. Nicht nur Geheimdienste sammeln dort Informationen und legen damit Datenbanken an, sondern zum Beispiel auch Versicherungsunternehmen. Diese werten die Daten des SocialWeb aus und versuchen, daraus wirksame Angebote für die Internetnutzer zu generieren ("Sie sind Mutter geworden. Dürfen wir Ihnen eine Ausbildungsversicherung anbieten…").

Doch nun zurück zu den "normalen" Anwendungsbereichen, vor allem zu denen in Unternehmen. In allen diesen Fällen interessiert beim Datenbankdesign nicht nur der Anwendungsbereich als solcher, sondern die in ihm realisierten Tätigkeiten, die Geschäftsprozesse, für die die Daten benötigt werden und in denen abzuspeichernde Daten entstehen. Anders ausgedrückt: Hier stellt sich beim Datenbankdesign zunächst die Frage, welche Daten die Geschäftsprozesse des Anwendungsbereiches benötigen und welche sie erzeugen.

Abstraktion. Nun ist so ein Anwendungsbereich sehr vielfältig. In ihm finden sich Aufgaben, Handelnde, Geschäftsobjekte (wie Rechnungen, Bestellungen Überweisungsbelege, usw.), Organisationsstrukturen und vieles mehr. Für das Datenbankdesign vereinfacht sich die Sache glücklicherweise, da können wir uns auf Objekte und - später - die Beziehungen zwischen ihnen konzentrieren. Das Finden dieser Objekte und Beziehungen wird im Rahmen der konzeptionellen Datenmodellierung geleistet.

Anwendungsbereiche mit Geschäftsprozessen

Geht es beim Datenbankentwurf um Organisationen (wie immer: Unternehmen, Körperschaften, Verwaltungen, usw.), dann gehört zur Analyse des Anwendungsbereichs auch die Analyse der in ihm realisierten Tätigkeiten (der Geschäftsprozesse), für die die Daten benötigt werden und in denen abzuspeichernde Daten entstehen. Anders ausgedrückt: Im Datenbankentwurf stellt sich in diesen Fällen zunächst die Frage, welche Daten die Geschäftsprozesse des Anwendungsbereiches benötigen und welche sie erzeugen.

Hier einige Beispiele für Anwendungsbereiche mit hoher Relevanz von Geschäftsprozessen:

• Anwendungsbereich GESAMTUNTERNEHMEN mit allen Geschäftsprozessen und Funktionen, die realisiert werden. Zum Beispiel, wenn für das Unternehmen eine umfassende Datenbank für eine ERP-Software erstellt werden soll.

• Anwendungsbereich ABTEILUNG EINES UNTERNEHMENS (z.B. Vertrieb, Beschaffung, Personalwesen) mit den dort vorliegenden Geschäftsprozessen und Funktionen.

• LOGISTIKKETTE einer Spedition

• HOTELKETTE mit weltweiten Buchungen

• INTERNETUNTERNEHMEN mit vollautomatisierten Geschäftsprozessen und umfassender Datenbank.

• Studienbetrieb einer HOCHSCHULE

• Markt für DATENBANKSYSTEME

• ANGESTELLTE eines Unternehmens

Die letzten drei sind hier didaktisch motiviert und tauchen - mit einfachen Beispielen - in den Kapiteln zur relationalen Modellierung immer wieder auf. Der Anwendungsbereich MARKT FÜR DATENBANKSYSTEME dient auch als Beispiel im SQL-Kapitel.

Obige Schriftgestaltung basiert auf den typographischen Festlegungen von Abschnitt 1.2.

3.2 Objekte und Beziehungen erkennen

Bei der Analyse des Anwendungsbereichs geht es im ersten Schritt darum, die (datenbanktechnisch wichtigen) Objekte und Beziehungen zu finden oder festzulegen. Denn genau diese werden in Datenbanken erfasst.

Der einfache Fall

Im einfachsten Fall nehmen wir Objekte und Beziehungen einfach wahr. Meist ist es jedoch nicht so einfach, sondern muss genauer geklärt werden. Dabei ist der Attributbegriff hilfreich. Denn Objekte und Beziehungen werden in Datenbanken durch ihre Attribute (in Feldern) beschrieben, diese macht sie für die Datenbank existent. Zu leisten ist dabei folgendes:

Schritt 1: Attribute identifizieren

Zuerst muss das Attribut gefunden werden, welches die Objekte und Beziehungen identifiziert. Dies ergibt sich oft von selbst, wie Fall einer Personalnummer oder einer eindeutigen Bezeichnung ("Bezeichnung Kraftfahrzeug"), muss aber oft auch gesucht oder festgelegt werden. Manchmal sind auch nur mehrere Attribute zusammen identifizierend, vor allem bei Beziehungen. Dazu später mehr. Möglich ist auch, dass es mehrere identifizierende Attribute zu denselben Objekten oder Beziehungen gibt. Dies führt dann in der Datenbank zu Primär- und Sekundärschlüsseln. Auch dazu unten mehr.

Schritt 2: Attribute festlegen

Der zweite Schritt besteht darin, die beschreibenden Attribute zu finden oder festzulegen. Dies ist ein wichtiger Schritt und einer der wohlbedacht sein muss:

Es werden genau die Attribute den Objekten bzw. Beziehungen zugeordnet, die für die Abwicklung der Geschäftsprozesse im zugehörigen Anwendungsbereich benötigt werden.

Früher sprach man statt von den Geschäftsprozessen, die durch die Datenbank unterstützt werden, vom Zweck der Datenbank. In einfachen Fällen ist auch heute noch diese Formulierung sinnvoll. Nehmen wir als Beispiel eine Datenbank, die eine einzelne Aufgabe unterstützen soll, z.B. die Absatzprognoserechnung für die Produkte eines Unternehmens. Hier werden die Attribute von dieser einzelnen Aufgabe abgeleitet.

Durch Analyse der Attribute

Eine im Bereich der relationalen Modellierung immer tragfähige Vorgehensweise ist die Identifizierung von Objekten (und danach auch von Beziehungen) durch Attributanalyse. Es gilt folgende Regel: Werden irgendwelche Realweltphänomene durch ein Attribut identifiziert, dann ist dieses erst mal ein einfaches beschreibendes Attribut.

Bsp. 1: Zum Beispiel Abteilungsbezeichnungen (AbtBez). Diese können den Angestellten zugewiesen werden, um festzuhalten, in welcher Abteilung sie arbeiten:

• Attribut: AbtBez

• Objekte: Angestellte

Bsp. 2: Oder die Personalnummern (PersNr) von Angestellten, durch die festgehalten wird, in welchen Projekten sie mitarbeiten:

• Attribut: PersNr

• Objekte: Projekte

Hier werden die Ausprägungen von PersNr den Projekten zugewiesen und halten fest, wer in welchem Projekt mitarbeitet.

Bsp. 3: Oder eine Angabe zu den von Angestellten eines Softwarehauses beherrschten Programmiersprachen, für jeden Angestellten seine wichtigste (ProgSpr):

• Attribut: ProgSpr

• Objekte: Angestellte

Identifizierung + Beschreibung => Objekt

Kommt nun aber bei der Beschreibung des Realweltphänomens zu der Benennung nur ein einziges beschreibendes Attribut dazu, erfolgt ein qualitativer Sprung: Die Beschreibung etabliert nun für die Datenmodellierung Objekte bzw. Beziehungen. In den obigen Beispielen:

zu Bsp. 1: Das Attribut AbtBez wird ergänzt durch das Attribut Abteilungsleiter (AbtLeiter) (und später noch viele mehr):

• Attribut 1: AbtBez

• Attribut 2: AbtLeiter

Jetzt geht es um Abteilungen (sie werden identifiziert und zusätzlich beschreiben). Abteilungen sind datenbanktechnisch zu Objekten geworden. Die Abteilungszugehörigkeit muss jetzt auf andere Weise erfasst werden.

zu Bsp. 2: Das Attribut PersNr wird ergänzt durch das Attribut Name (und später noch viele mehr):

• Attribut 1: PersNr

• Attribut 2: Name

Jetzt geht es um Angestellte (sie werden identifiziert und zusätzlich beschrieben), sie sind datenbanktechnisch zu Objekten geworden. Die Projektmitarbeit muss jetzt auf andere Weise erfasst werden.

zu Bsp. 3: Das obige Attribut ProgSpr wird ergänzt um das Attribut (verwendeter) Compiler :

• Attribut 1: ProgSpr

• Attribut 2: Compiler

Jetzt geht es um Programmiersprachen (sie werden identifiziert und zusätzlich beschrieben), auch sie sind datenbanktechnisch zu Objekten geworden. Die Programmierkompetenz muss jetzt auf andere Weise erfasst werden.

Jeweils ein weiteres Attribut genügt also für die Etablierung der Objekte und Beziehungen. Für Beziehungen gilt dies genauso, wenn ein einzelnes Attribut die Beziehung identifiziert ("Transaktionsnummer"). Meist werden in der relationalen Modellierung aber (mindestens) zwei Attribute zur Identifizierung von Beziehungen benötigt (vgl. Kapitel 5).

Mit obigem Regelwerk ist es einfach, Objekte und Beziehungen im datenbanktechnischen Sinn zu erkennen:

Wird ein Realweltphänomen durch ein Attribut (oder mehrere) identifiziert und durch mindestens ein weiteres beschrieben, handelt es sich datenbanktechnisch um ein Objekt oder eine Beziehung.

Vgl. zur Schriftgestaltung die typographischen Festlegungen von Abschnitt 1.2.

Schritt 3: Klassen bilden

Im nächsten Schritt werden alle gleich strukturierter Objekte und Beziehungen zusammengefasst. "Gleich strukturiert" bedeutet hier "dieselben Attribute besitzen". Daraus entstehen dann Gruppen gleichartiger Objekte und Beziehungen, die Klassen genannt werden:

Die Objekte und Beziehungen, die dieselben Attribute besitzen, werden zu Objektklassen bzw. Beziehungsklassen zusammengefasst.

Dies erfolgt oft schon automatisch beim ersten Schritt, beim Erkennen der Objekte und Beziehungen, wo wir unbewusst schon gleich an alle Studierende, an alle Angestellten, usw. denken, wenn wir die entsprechenden Objekte wahrnehmen. Diese Klassenbildung ist aber nicht immer so einfach und muss auf jeden Fall über die Attribute überprüft werden. Dies soll an einigen der oben eingeführten Beispiele verdeutlicht werden.

Exkurs für alle, die mit der objektorientierten Theorie vertraut sind:

So wie der Begriff Klasse hier verwendet wird, ist er durchaus verträglich mit dem entsprechenden Begriff der objektorientierten Theorie. Er soll aber nicht gleich gesetzt werden, denn dort gehört noch mehr dazu: Klassenattribute, Methoden, usw. Vgl. für eine Einführung [Staud 2019].

3.3 Beispiele

Studienbetrieb einer Hochschule

Im Studienbetrieb einer Hochschule sind unschwer die Objekte Studierende, Dozenten, Vorlesungen und Veranstaltungsräume zu erkennen. Sie werden identifiziert und beschrieben:

• Studierende z.B. durch eine Matrikelnummer (MatrNr), den Namen, Vornamen, usw.

• Dozenten durch eine Dozentennummer (DozNr), das gehaltene Fach, usw.

• Vorlesungen durch ihre Kurzbezeichnung (BezVorl), das Semester, in dem sie gehalten werden, usw.

• Veranstaltungsräume durch ihre Bezeichnung (BezRaum), die Anzahl der Sitzplätze, die Ausstattung, usw.

Auch eine Beziehung ist gleich erkennbar: Vorlesungsbesuch . Sie könnte Vorlesungen, Studierende und Dozenten verknüpfen. Vorlesungen und Veranstaltungsräume könnten auch einfach nur beschreibende Attribute bei anderen Objekten oder Beziehungen sein, z.B. bei Vorlesungsbesuch. Alle diese Objekte und Beziehungen werden dann auch zu Klassen.

Markt für Datenbanksysteme

Im Markt für Datenbanksysteme sind auf Anhieb folgende Objekte erkennbar, die dann auch zu Objektklassen aggregiert werden:

• die Datenbanksysteme selbst, z.B. Oracle , DB2 , ACCESS , MySQL , CouchDB

• die Firmen, die diese Software programmieren lassen und auf den Markt bringen: Oracle, IBM, Microsoft usw.

• die Händler, die diese Software dem Endkunden zum Verkauf anbieten

Ebenfalls sofort erkennbar sind die Beziehungen "stellt her" und "bietet an". Erstere stellt die Datenbanksysteme mit den Produzenten in Beziehung, letztere die Datenbanksysteme mit den Händlern. Objekte und Beziehungen werden diese aber nur, weil wir auch sofort Attribute erkennen, auch identifizierende, die dann zu Schlüsseln werden (Bsp. Produktname, Firmenname, Händlername usw.).

Auch die beschreibenden Attribute sind leicht zu finden. Für die Datenbanksysteme liegen die Attribute Bez (Bezeichnung), Typ (relationales Datenbanksystem, objektorientiertes Datenbanksystem, NoSQL-System, …), Plattform und deren jeweiliger Listenpreis (LPreis) nahe. Für die Produzenten (also die Unternehmen Oracle, IBM, Microsoft usw.) könnte man die Attribute Bez , Land und die Adresse im World Wide Web (WWW) erfassen. Für die Händler liegen die Attribute Bez , Ort , Straße , Telefonnummer (Tel) und Mailadresse (EMail) nahe.

Bezüglich der Beziehung "Händler bietet ein Datenbanksystem auf dem Markt an" (bietet an) könnte der Preis festhalten werden, zu dem dies geschieht. Die Beziehung "Produzent stellt ein Datenbanksystem her" (stellt her) könnte Attribute wie Beginn und Ende erhalten.

Die folgende Tabelle fasst die jetzt festgelegten Objektklassen und Beziehungsklassen mit ihren Attributen zusammen.

(Markt für) DATENBANKSYSTEME

Objekt-, Beziehungsklasse	Attribute
Datenbanksysteme	Bez, Typ, Plattform, LPreis
Produzenten	Bez, Land, WWW
Händler	Bez, Ort, Straße, Tel, EMail
bietet an	Preis
stellt her	Beginn, Ende

Die Klassenbildung ist nicht immer so einfach wie in diesen Beispielen. Würden wir uns z.B. dazu entschließen, für die einzelnen Arten von Datenbanksystemen spezifische Attribute zu erfassen, z.B. Dokumentart für NoSQL-Datenbanksysteme oder die Art der Vererbungstechnik bei objektorientierten Systemen, könnten wir diese nicht in einer einzigen Objektklasse zusammenpacken. Sie müsste aufgespaltet werden (vgl. dazu Abschnitt 14.1).

3.4 Zusammenfassung

Die konzeptionelle Modellierung für relationale Datenbanken klärt die für die Anwendung wichtigen Objekte und Beziehungen und - in einem ersten Schritt, der später verfeinert wird - deren Aggregation zu Objekt- und Beziehungsklassen. Dies geschieht wesentlich durch die Analyse der Attribute. Kurz gefasst gilt:

Ein Realweltphänomen, das durch ein Attribut (oder mehrere) identifiziert und durch mindestens ein weiteres beschrieben wird, ist datenbanktechnisch existent und wird zu einem Objekt oder einer Beziehung. Objekte und Beziehungen, die dieselben Attribute habe, werden zu Objekt- bzw. Beziehungsklassen zusammengeführt.

Soweit der erste Schritt, das Erkennen von Objekten und Beziehungen. Er führt in der Regel zu einer Vielzahl von Informationen, die weiter strukturiert werden. Bei dieser Strukturierung kann es auch ohne weiteres geschehen, dass Objekte als solche wieder verschwinden oder dass neue entstehen.

Schrittweises Verfeinern. Obwohl dieses Zusammenstellen von Objekten und Beziehungen nur den Einstieg darstellt, ist es der erste und wichtige Schritt bei der Erstellung eines Datenmodells. Am besten führt man ihn so durch, dass alle Beteiligten ihre Ideen und Vorschläge zusammentragen. Zu den Beteiligten gehören neben den Datenbankspezialisten auch die zukünftigen Nutzer der Datenbank, z.B. Mitarbeiter des Lagers, wenn es um eine Datenbank für das Lagerwesen geht oder Mitarbeiter der Beschaffung, wenn das Beschaffungswesen in einer Datenbankanwendung erfasst werden soll. Oftmals fallen die beiden Gruppen allerdings zusammen oder die Nutzergruppe steht erst mal nicht zur Verfügung.

Mehr Semantik

Obiges Erfassen von Objekten und Beziehungen ist der erste Schritt. Anschließend erfolgt die Erfassung weiterer semantischer Aspekte, die für den Anwendungsbereich wichtig sind. Nur um dies anzudeuten, hier ein Beispiel:

Beispiel Lehrbetrieb. In einer Hochschule könnten folgende Grundsätze unserer Daseins zur Semantik gehören und bei der Gestaltung einer Datenbank zum Lehrbetrieb wichtig sein:

• In einem Raum kann in einer Zeitspanne nur eine Veranstaltung stattfinden.

• Ein Dozent kann in einer Zeitspanne nur einen Kurs abhalten.

• Ein Dozent sollte pro Tag nicht mehr als 6 Stunden Vorlesungen und Übungen geben.

• Die Semesterpläne müssen die aktuelle Studienordnung umfassend widerspiegeln.

• Veranstaltungen, die das lokale PC-Netz zum Absturz bringen könnten (z.B. Programmierkurse) sollten nicht am Freitag Nachmittag stattfinden, da ab 13.00 Uhr die Rechenzentrumsmitarbeiter nicht mehr da sind, um einen evtl. Netzzusammenbruch "zu reparieren".

usw. Wenigstens ein kleiner Teil solcher Semantikaspekte kann in Datenmodellen und später in Datenbanken erfasst werden, was zu den oben schon erwähnten semantischen Integritätsbedingungen führt.

Datenbank oder Anwendungsprogramme? Woher kommt der Wunsch, möglichst viel Semantik des jeweiligen Weltausschnitts in einem Datenmodell und dann in der Datenbank zu erfassen? Nun, die Semantik³ gehört zur Anwendung. Sie muss auf jeden Fall berücksichtigt werden, soll die Anwendung leistungsstark sein⁴. Entweder wird sie in der Datenbank hinterlegt oder in den Programmen rund um die Datenbank softwaretechnisch realisiert (dann ist ihre Erfassung Gegenstand der Systemanalyse).

Die Hinterlegung in der Datenbank, aufbauend auf der vorangehenden Berücksichtigung beim Datenbankentwurf, hat aber Vorteile: Sie ist sehr übersichtlich (z.B. als Semantische Integritätsbedingungen (constraints) auf den Relationen) und leicht änderbar. Man kann es auch so formulieren:

Alle (zu berücksichtigende) Semantik, die nicht in der Datenbank hinterlegt wird, muss bei der Systemanalyse für die Anwendungsprogramme umfassend umgesetzt werden.

Internet, BigData. Allerdings hat uns die jüngste Vergangenheit gelehrt, dass in bestimmten Anwendungsbereichen (Internet, BigData) die durch die Erfassung von Semantik erforderliche größere Komplexität der Datenstrukturen hinderlich ist. Das beginnt schon bei einfacher referentieller Integrität (vgl. Kapitel 5) und verschärft sich bei komplexeren semantischen Integritätsbedingungen.

Vertiefung

Die Ausführungen in diesem Kapitel stellen nur die Grundlagen der konzeptionellen Modellierung dar. Für eine vertiefte Betrachtung empfiehlt sich die einschlägige Literatur, z.B. [Olivé 2007]. Vieles spielt sich hier allerdings in Tagungen und deren Tagungsbändenab. Vgl. beispielhaft [Ng, Storey, Trujillo et al. 2013].

3 Es geht natürlich nur um den Teil der Semantik, der für die jeweilige Anwendung bzw. für die Geschäftsprozesse, denen die Datenbank "dient", Bedeutung hat.

4 Zur Illustration stelle man sich nur eine Software für den oben skizzierten Lehrbetrieb vor. An einer solchen und an den entsprechenden Datenbanken durfte der Verfasser viele Jahre arbeiten.