Читать книгу Relationale Datenbanken - Josef Ludwig Staud - Страница 13
Оглавление4 Relationen bilden
Die oben gefundenen Objekte und Beziehungen werden nun zu einem relationalen Datenmodell zusammengeführt, mit dessen Hilfe dann später mit Hilfe eines relationalen Datenbanksystems die Datenbank erstellt wird. Ein Datenmodell ist ein Abbild des jeweiligen Anwendungsbereichs, das mit den Mitteln und gemäß den Regeln des jeweiligen datenbanktheoretischen Ansatzes realisiert wurde. In den nächsten Kapiteln wird nun betrachtet, welche "Mittel und Regeln" die relationale Theorie für die Erstellung von Datenmodellen zur Verfügung stellt.
Andere Modellierungstheorien haben natürlich andere Werkzeuge. Um nur die beiden "benachbarten" zu nennen: Die ER-Modellierung benutzt neben wichtigen Metaregeln u.a. Entitäts- und Beziehungstypen, um zu Modellen zu kommen, die objektorientierte (Daten)Modellierung Klassen, Methoden, Assoziationen, usw.
4.1 Von Klassen zu Relationen
Im nächsten Schritt wird nun jede der oben eingeführten Objekt- und Beziehungsklassen - falls letztere in der konzeptionellen Datenmodellierung bereits gefunden wurden - in einer Tabelle erfasst. Dies geschieht wie folgt:
• die Attributsbezeichnungen stehen im Kopf der Spalten
• darunter folgen Zeile für Zeile die Attributsausprägungen, die ein Objekt bzw. eine Beziehung beschreiben, geordnet nach der Attributsanordnung in der Kopfzeile. Diese Zeilen werden in der relationalen Theorie Tupel genannt.
Beispiel: Objektklasse Angestellte
Betrachten wir das Beispiel der Objektklasse Angestellte . Die Tabelle kann (in einfacher und abstrahierter Form) so aussehen, wie unten angegeben. Die Angestellten werden durch folgende Attribute beschrieben:
• Personalnummer (PersNr)
• Name
• Vorname (VNname)
• Datum der Einstellung (DatEinst)
• Geburtstag (GebTag)
Schlüssel: Definition 2
Eines der Attribute muss identifizierenden Charakter haben, hier ist es die Personalnummer. Es wird Schlüssel (der Relation) genannt und durch eine Raute gekennzeichnet (mehr dazu weiter unten). Für die Objektklasse Angestellte entsteht also eine Tabelle wie die folgende:
Tabelle Angestellte
| PersNr | Name | VName | DatEinst | GebTag |
| 1001 | Müller | Karolin | 1.3.2010 | 14.5.1985 |
| 1010 | Jäger | Rolf | 1.10.1990 | 21.9.1959 |
| 1020 | Wilkens | Jenny | 1.1.2007 | 23.3.1970 |
| 1030 | May | Karl | 1.10.2010 | 31.7.1985 |
| 1005 | Sommer | Lisa | 1.7.2009 | 21.9.1970 |
| 1040 | Winter | Angelika | 1.2.2007 | 17.9.1965 |
| 1007 | Müller | Igor | 1.5.2008 | 22.11.1962 |
| 1090 | Stepper | Rolf | 1.7.2013 | 15.4.1974 |
Betrachten wir noch ein zweites Beispiel, die Objektklasse Abteilungen mit den Attributen:
• Bezeichnung der Abteilung (AbtBez)
• Leiter der Abteilung (AbtLeiter)
• Standort der Abteilung
Hier ergibt sich folgende Tabelle
Tabelle Abteilungen
| AbtBez | AbtLeiter | Standort |
| PW | Sommer | München |
| IT | Winter | Ulm |
| RE | Müller | München |
| VB | Stepper | München |
PW=Personalwesen, IT=Datenverarbeitun, RE=Rechnungswesen, VB=Vertrieb
Nun noch die Objektklasse der Projekte . Für diese wird eine Bezeichnung (Bez), der Tag der Einrichtung (TagEinr), die Dauer und das Budget erfasst.
Tabelle Projekte
| Bez | TagEinr | Dauer | Budget |
| LiefPortal | 1.10.2013 | 60 | 200 |
| Ind4p0 | 1.1.2014 | 48 | 600 |
| BPM | 1.4.2013 | 48 | 150 |
Abschließend noch die Objektklasse PC . Sie beschreibt die im Unternehmen benutzten PCs.
Tabelle PC
| InvNr | Bez | Typ |
| pc2012 | … | Desktop Büro |
| pc3015 | … | Desktop Entwickler |
| Pc1414 | … | Laptop |
Von Tabellen zu Relationen
Genau solche Tabellen werden, wenn sie bestimmte Eigenschaften haben, Relationen genannt. Relationen sind also - auf dieser Ebene der Modellierung - nichts anderes als nach bestimmten Regeln gestaltete Tabellen, mit denen jeweils eine Objekt- oder Beziehungsklasse beschrieben wird.
Die Beziehungen und Beziehungsklassen betrachten wir in Kapitel 5. Somit besteht der nächste Schritt im Modellierungsprozess darin, für jede Objektklasse eine Relation anzulegen. Damit verlassen wir auch den Bereich der konzeptionellen Modellierung und beginnen mit der relationalen Modellierung.
4.2 Eigenschaften und Darstellung von Relationen
Folgendes sind die Eigenschaften, die eine Tabelle erfüllen muss, um zur Relation zu werden:
Eigenschaften von Relationen
(1) Jede Zeile (auch "Reihe" oder "Tupel") beschreibt ein Objekt (bzw. eine Beziehung), die Tabelle als Ganzes beschreibt die Objekt- oder Beziehungsklasse.
(2) In jeder Spalte steht als Kopf der Name eines Attributs, darunter stehen die Attributsausprägungen, die das jeweilige Objekt (die Beziehung) beschreiben.
(3) Eine Relation hat immer einen Schlüssel, der auch aus mehr als einem Attribut bestehen kann, und mindestens ein beschreibendes Attribut.
(4) Es gibt keine zwei identischen Tupel, d.h. jedes Tupel beschreibt ein anderes Objekt.
(5) Im Schnittpunkt jeder Zeile und Spalte wird genau eine Attributsausprägung festgehalten, nicht mehr. Dies macht die Tabelle zur flachen Tabelle.
Zu 1: Dies ist am Anfang der Erstellung eines Datenmodells richtig. Später, wenn eventuelle Redundanzen in den Modellentwürfen beseitigt werden - Stichwort Normalisierung (vgl. die Kapitel 7 - 13) - werden die Attribute zu einem Objekt u.U. auf mehrere Relationen und damit auf mehrere Tupel verteilt.
Zu 2: So wurden die Tabellen ja oben bereits eingeführt.
Zu 3: Denn ein Schlüssel alleine hat nicht allzuviel Aussagekraft.
Zu 4: Dies kann man auch mit der mathematischen Herleitung der relationalen Theorie begründen, vgl. [Staud 2006, Abschnitt 3.22]. Es genügt aber auch, sich klar zu machen, dass zwei Tupel einer Relation mit demselben Schlüssel und denselben Attributen keinen Sinn machen, denn sie beschreiben ja dasselbe Objekt bzw. die dieselbe Beziehung.
Flachheit – Mehrfacheinträge - Wiederholungsgruppen
Zu 5: Die letztgenannte Eigenschaft ist besonders wichtig in der relationalen Theorie und bereitet beim Aufbau einer Datenbank (bei der Erstellung des Datenmodells) auch einige Schwierigkeiten. Sie bedeutet konkret, dass eine Tabelle umorganisiert werden muss (mehr dazu in Kapitel 7), wenn einem Objekt mehr als eine Ausprägung eines Attributs zugeordnet werden kann. Man spricht dann von Mehrfacheinträgen oder auch Wiederholungsgruppen (repeating groups). Wäre z.B. in der folgenden Abbildung auch das Attribut BezProj (Projektbezeichnung) mitaufgeführt (Projekte, in denen die Angestellten mitarbeiten), könnten Mehrfacheinträge entstehen, wenn ein Angestellter in mehreren Projekten mitarbeitet.
Die oben eingeführten Tabellen erfüllen alle diese Anforderungen und können deshalb als Relationen weiter geführt werden.
Im Mittelpunkt: Flache Tabellen
Auf diesen Relationen und nur auf ihnen beruht die relationale Theorie und auf diesem wiederum die Relationalen Datenbanksysteme (RDBS). Alle Objekt- und Beziehungsklassen werden durch Relationen erfasst und nur durch diese.
Auch die relationalen Datenbanksysteme sind voll auf diesen Informationstyp zugeschnitten. Sie besitzen Befehle zum Einrichten dieser Relationen, zum Festlegen der Attribute usw. Sie erlauben dann, Relationen miteinander zu verknüpfen und auszuwerten, usw.
Die folgende Abbildung zeigt, wie Relationen als Tabellen dargestellt werden können und wie sie aufgebaut sind. Zu jeder Relation gehört eine Bezeichnung, hier Angestellte. In der obersten Zeile stehen die Bezeichnungen der Attribute. Hier sind schon mal Schlüssel (identifizierendes Attribut) und Fremdschlüssel markiert, sie werden unten erläutert. In den Zeilen darunter stehen die Ausprägungen der in der Kopfzeile angegebenen Attribute. Diese Zeilen werden in der relationalen Theorie Tupel genannt. Somit beschreibt ein Tupel ein Objekt oder eine Beziehung (vgl. dazu den nächsten Abschnitt). Die Attribute, die Fremdschlüssel sind, dienen zur Verknüpfung, vgl. die Definition oben und die genauere Darstellung im nächsten Abschnitt.
Darstellung 1: didaktisch motivierte grafische Darstellung
Abbildung 4.2-1: Aufbau von Relationen.
Vgl. zu den verwendeten Abkürzungen die Erläuterungen oben.
Darstellung 2: textliche Darstellung
Neben dieser grafischen Darstellung wird für Relationen auch die folgende textliche Schreibweise benutzt:
RELATIONENNAME (#A1, A2, A3, …)
Dabei stehen A1, A2 usw. für die Attribute der Relation. Die Raute kennzeichnet das Schlüsselattribut. Für das Beispiel oben also:
Angestellte (#PersNr, Name, VName, …)
Mehrere Attribute im Schlüssel
Es kommt vor, dass der Schlüssel einer Relation aus mehreren Attributen besteht, z.B. bei bestimmten Beziehungen (vgl. dazu den nächsten Abschnitt). Dann werden die Schlüsselattribute (hier A1 und A2) in Klammern gefasst:
RELATIONENNAME (#(A1, A2), A3, A4, …)
Soll ein Attributsnamen um die Angabe seiner Relation ergänzt werden (z.B. in SQL, wo es teilweise unabdingbar ist), wird der Relationenname voran gestellt:
RELATIONENNAME.Attributname
Also z.B. Angestellte.Name oder Abteilungen.AbtLeit .
Hier nun alle obige Relationen zum Anwendungsbereich ANGESTELLTE in dieser textlichen Darstellungsweise:
Angestellte (#PersNr, Name, VName, DatEinst, GebTag)
Abteilungen (#AbtBez, AbtLeiter, Standort)
Projekte (#Bez, TagEinr, Dauer, Budget)
PC (#InvPC, Bez, Typ)
Die Schlüssel bedeuten:
• PersNr: Pesonalnummer
• AbtBez: Kurzbezeichnung der Abteilung
• InvPC: Inventarnummer des PC
• ProjId: Identifizierende Information für PCs
Darstellung 3: Eigentliche grafische Darstellung von Relationen
Die eigentliche grafische Darstellungsweise für Relationen ist wie in der folgenden Abbildung angegeben. In einem Rechteck wird in der oberen Hälfte der Relationenname angegeben, darunter die Schlüssel und Fremdschlüssel5 (und nur diese). Diese Darstellung wird benötigt, wenn ganze Datenmodelle (also viele Relationen mit ihren Verknüpfungen) dargestellt werden sollen (vgl. hierzu Kapitel 7 bis 13 und insbesondere die zahlreichen Beispiele in den Kapiteln 16 und 17).
Abbildung 4.2-2: Grafische Darstellung von Relationen
Beispiele aus dem Anwendungsbereich ANGESTELLTE
In dem in diesem Abschnitt eingeführten Beispiel soll es um den Anwendungsbereich ANGESTELLTE eines Unternehmens (in vereinfachter Form) gehen. Hier die grafische Darstellung der vier Relationen.
Abbildung 4.2-3: Relationen aus dem Anwendungsbereich ANGESTELLTE
Beispiele aus dem Anwendungsbereich RECHNUNGSSTELLUNG
Vgl. hierzu die zusammenhängende Darstellung in Abschnitt 16.1. Dort ist auch eine abstrahierte Rechnung angegeben.
In diesem zweiten Beispiel soll es um den Anwendungsbereich RECHNUNGSSTELLUNG gehen. Erfasst werden die Informationen rund um die Rechnungen (Typ Möbelhaus). Im ersten Schritt legen wir die Relationen Kunden , Artikel , ReKöpfe (Rechnungsköpfe) und Lagerort an. Hier die textliche Fassung der Relationen mit den Schlüsseln. Weitere Attribute werden folgen.
Kunden (#KuNr, …)
Artikel (#ArtNr, …)
ReKöpfe (#ReNr, …)
Lagerort (#LoId, …)
Die Schlüssel bedeuten:
• ArtNr : Artikelnummer
• LoId : Lagerortidentifikation
• ReNr : Rechnungsnummer
• KuNr : Kundennummer
Hier die grafische Darstellung der Relationen.
Abbildung 4.2-4: Relationen aus dem Anwendungsbereich RECHNUNGSSTELLUNG
Grundbegriffe
Soweit die Relationen der einführenden Beispiele und ihre Darstellung. Die folgende Tabelle fasst die Grundbegriffe zu Relationen zusammen. Dabei sind die Begriffe der datenbanktheoretischen Diskussion um die informellen Begriffe ergänzt, soweit solche existieren.
Relationale Begrifflichkeit
| Informell | Formell | Englisch |
| Tabelle | Relation | Table |
| Zeile | Tupel | row, tuple |
| Eigenschaft - Bezeichnung | Attribut(sname) | attribute |
| Eigenschaft - Ausprägung | Attributsausprägungen, Wertebereich | domain |
5 Fremdschlüssel dienen der Verknüpfung verschiedener Relationen miteinander und sind deshalb von großer Bedeutung in der relationalen Modellierung. Sie werden im nächsten Kapitel erläutert.
