1 Datenmodelle für Datenbanksysteme

Technische Datenorganisation
Alexander Stadlmann 4.HBa 1995/96
1 Datenmodelle für Datenbanksysteme
Wir unterscheiden verschiedene Modelle, die in Datenbanksystemen verwendet werden und im
folgenden Kapitel ausgeführt sind.
1.1 Datenmodelle (allgemein)
Ein Datenmodell ist ein mathematischer Formalismus mit zwei Teilen:
• Eine Schreibweise um Daten zu beschreiben.
• Eine Reihe von Operationen um die Daten zu manipulieren.
Das eine Modell ist das relationale Modell, wo die Schreibweise um Daten zu beschreiben auf
Attributen basiert (Spalten). Das andere Modell ist das Netzwerkmodell, welches Diagramme
verwendet, um Daten zu identifizieren.
Es werden nun Unterschiede zwischen den Modellen aufgelistet, die beeinflussen wo und wann sie
ihre beste Verwendung finden:
a) Zweck: Viele Modelle beabsichtigen als Schreibweise für Daten in Datenbanken und als
grundlegende Schreibweise für die Datenmanipulationssprache zu dienen. Auf der anderen Seite
beabsichtigt das „Entity-Relationship-Model“ eine Schreibweise für ein begriffliches (von Begriff)
Schema.
b) Objekt- und Wertorientierung: „Wertorientierte Modelle“ sind das relationale und logische
Modell. Das Netzwerk-, Hierarchische- und Objektmodell, jedes ausgestattet mit Objektidentität,
kann als „objektorientiert“ angesehen werden. Das „Entity-Relationship-Model“ erfordert
ebenfalls Objektidentitäten.
c) „Handeln mit Überflüssen“: Alle Modelle haben eine Hilfe für den User integriert, um gleiche
Fakten nicht mehr als einmal speichern zu können. Solche Überflüsse verschwenden nicht nur
Platz, sondern sie können auch Widersprüchlichkeiten zwischen Daten verursachen, da manchmal
Fakten in einer aber nicht in die andere Richtung gewechselt gehören. Objektorientierte Modelle
eignen sich besser um mit „Überflüssen zu handeln“, da sie eine eigene Kopie eines Objekts
anlegen und mittels Zeiger von den verschiedensten Plätzen darauf hinweisen.
d) „Handeln mit m:n Beziehungen“: Oft kommt es vor, daß Datenmodelle m:n Beziehungen
speichern sollen, in welcher jede von einer Gruppe von Elementen auf viele Elemente einer
anderen Gruppe bezogen ist.
Beispiel: Kurse und Studenten. Ein bezeichnender Student, belegt mehrere Kurse und ein
bezeichnender Kurs wird von mehreren Studenten besucht. Das Problem besteht darin, die
geeignete Speicherstruktur zu entwickeln, welche eine effiziente Abfrage erlaubt.
1.2 Das „Entity-Relationship-Model“
Der Zweck vom „Entity-Relationship-Model“ ist eine Beschreibung eines begrifflichen Schemas zu
erlauben, ohne der Vernachlässigung der Aufmerksamkeit zur Effizienz oder dem physikalischem
Datenbankdesign. Es ist normalerweise vom „Entity-Relationship-Diagramm“ übernommen, so
konstruiert, das sie später in begriffliche Schemen eines anderen Modells, z.B. eines relationalen
Modells, umgedreht werden können.
1.2.1 Entities (ein spezielles Objekt)
So wie ein Punkt und eine Linie in der Geometrie nur im Unterschied ihrer Proportionalität definiert
sind, so ist es auch mit den Entities. Es genügt zu sagen, daß sie existierende Dinge definieren und
unterscheidbar sind bzw. sein müssen.
Beispiel: Jede Person oder jedes Auto sind Entities. Man kann auch jede Ameise als Entity
betrachten, wenn sie sich in irgend einer Art und Weise von einander unterscheiden. (Nummern)
1.2.2 Entity Sets (Tabelle; Einheitensatz)
Eine Gruppe, welche gleiche Entities enthält, formt ein „Entity Set“.
Beispiele:
1
Technische Datenorganisation
Alexander Stadlmann 4.HBa 1995/96
• alle Personen
• alle rothaarigen Personen
• alle Autos
Bei Beispiel 1 und 2 ist das Wort „gleiche Entities“ nicht präzise definiert und kann eine unendliche
Nummer von verschiedenen Eigentumsrechten schaffen, welches eine Tabelle definiert.
Es ist notwendig alle Mitglieder einer Reihe mittels Sammeln von Eigenschaften, genannt Attribute,
zu charakterisieren.
Beispiel 1.1: Die kalifornische Abteilung für Motoren kreiert ein Datenbanksystemsschema um ein
Tabelle, namens „AUTOMOBILS“ zu haben. Im gegenwärtigen Beispiel dieser Entity Reihe sind alle
Autos in Kalifornien registriert, aber nicht alle Autos der ganzen Welt oder alle Autos jemals
existieren können.
1.2.3 Attribute und Schlüsseln
Tabellen haben Eigenschaften, genannt Attribute, welche mit der jeder Entität im Satz verbunden
sind. Normalerweise besteht der Inhalt von Attributen aus Ganzzahlen, Gleitkommazahlen oder
Zeichenketten.
Die Auswahl von relevanten Attributen für Tabellen ist ein anderer kritischer Schritt im kreiren eines
Datenbankschemas. Ein Attribut oder ein Satz von Attributen, welche Werte einen Datensatz einmalig
identifizieren wird Schlüssel für die Tabelle genannt. Im Prinzip, hat jede Tabelle einen Schlüssel,
seitdem wir festgestellt haben, daß sich jeder Datensatz von allen anderen unterschiedet. Aber wenn
wir keinen Satz von Attributen haben, welche einen Schlüssel beinhalten, dann sind wir nicht in der
Lage einen Datensatz von den anderen zu unterscheiden. Eine willkürliche Seriennummer ist oft als
ein Attribut ausgestattet, um als Schlüssel zu dienen.
Beispiel 1.2: Eine Tabelle, die nur U.S. Staatsbürger enthält, kann das einzelne Attribut der „Social
Security Number“ als Schlüssel verwenden. Wie auch immer, vorausgesetzt wir wollen einmalige
Bewohner einer Tabelle, welche die Bevölkerung von mehreren Ländern beinhaltet, dann können wir
nicht sicher sein, daß zwei Länder nicht dieselbe Identifizierungsnummern verwenden, so daß ein
verwendeter Schlüssel ein Paar von Attributen ID_NO und COUNTRY sein könnte.
1.2.4 Isa Hierarchie
Wir sagen A isa B, gelesen „A is a B“, wenn Tabelle B eine Verallgemeinerung von einer Tabelle A
ist, oder gleichwertig, A ist ein spezieller Teil von B. Der primäre Zweck im deklarieren von isa
Relationen zwischen Tabellen A und B ist, daß A die Attribute von B erben kann, aber hat auch einige
zusätzliche Attribute, die keinen Sinn für jene Teile von B machen, welche auch keine Teile von A
sind. Jeder Datensatz a in Tabelle A ist genau mit einem Datensatz b von Tabelle B in Beziehung, so
daß a und b wirklich derselbe Datensatz sind.
Beispiel 1.3: Eine Firma hat eine Tabelle EMPLOYEES mit den Attributen wie ID_NO, NAME und
SALARY. Wenn die Firma eine Baseballmannschaft wäre, gewisse Angestellte die Spieler wären,
würden sie andere wichtige Attribute haben, wie BATTING_AVG oder HOME_RUNS, welche die
Angestellten nicht haben. Der vernünftigste Weg um dieses Schema zu entwerfen ist, eine andere
Tabelle zu haben, mit der Relation PLAYERS isa EMPLOYEES. Attribute wie Name, gehören zu
EMPLOYEES und auch PLAYERS, aber nur PLAYERS haben Attribute wie BATTING_AVG.
1.2.5 Beziehungen
Eine Beziehung unter Tabellen, ist eine geordnete Liste von Tabellen. Ein besondere Tabelle darf
mehr als einmal in der Liste erscheinen. Diese Liste von Tabellen ist die Schemen-EbenenVorstellung einer Beziehung. Wenn eine Beziehung R unter Tabellen E1, E2, ..., Ek besteht, dann ist
das aktuelle Beispiel von R ein Satz von k-fach. Wir nennen solch einen Satz einen Beziehungssatz.
Beispiel 1.4: Angenommen wir haben eine Tabelle PERSONS und wir haben eine Beziehung
MOTHER_OF, welche eine Liste von Tabellen PERSONS, PERSONS ist. Der Beziehungssatz von
Beziehung MOTHER_OF besteht aus den Paaren (p1, p2), wo diese Person p2 die Mutter von Person
p1 ist.
2
Technische Datenorganisation
Alexander Stadlmann 4.HBa 1995/96
Ein alternativer Weg um diese Information zu repräsentieren, ist die Existenz der Tabelle MOTHERS
und Beziehung MOTHERS isa PERSONS zu übertragen. Diese Anordnung, Vereinbarung würde sich
mehr eignen, wenn die Datenbank Werte speichert, die für Attribute von Müttern, die normalerweise
für Personen nicht gespeichert werden. Dann würde die Beziehung MOTHER_OF eine Liste von
Tabellen PERSONS, MOTHERS sein.
Um die Information über die Mutter einer Person als Person zu erhalten, würden wir die
Beziehungen MOTHER_OF und isa zusammensetzen (im Sinne von üblichen Satz-theoretischen
Beziehungen).
1.2.6 Geborgte Schlüsselattribute
Wir erwähnten in Verbindung mit isa Beziehungen, daß wenn A isa B, dann der Schlüssel von A
natürlich das Schlüsselattribut von B sein, und diese Attribute würden nicht als Attribute der Tabelle
A erscheinen. Somit würde im Beispiel 1.3 der Schlüssel für Tabelle PLAYERS natürlich das Attribut
ID_NO von EMPLOYEES sein. Dann würde ein Spieler einzigartig von ID_NO von dem Angestellten,
welcher er ist, identifiziert werden.
Beachte, das wenn Schlüsselattribute geborgt sind, es wichtig ist, daß aus der Beziehung ein
eindeutiger Datensatz in der Zieltabelle folgt. Das muß der Fall sein, wenn eine isa Relation folgt,
aber es braucht nicht der Regelfall sein, z.B. stellt sich die Frage, ob Personen Bürger von zwei
Ländern sein können? Kurzerhand, sollen wir die Bedeutung der Funktionalität von Beziehungen
untersuchen, welches uns mitteilt, wenn ein Datensatz von einer Tabelle in Relation mit einer
teilweisen Beziehung zu einem einzigartigen Mitglied von einer anderen Tabelle steht.
1.2.7 Entity-Relationship Diagramme
Es ist hilfreich die Informationen mit Hilfe der ERD´s zusammenzufassen, wo:
a) Rechtecke Tabellen entsprechen
b) Kreise Attribute entsprechen. Sie sind zu ihren Tabellen mit Linien verbunden. Manchmal werden
Attribute, die ein Teil des Schlüssels sind, unterstrichen. In einem speziellen Fall wird, betreffend
Attribute, manchmal eine Tabelle identifiziert, welche nur ein Attribut hat. Mit dem Attribut selbst
benennen wir die Tabelle nach dem Namen des Attributes. In diesem Fall erscheint die Tabelle als
ein Kreis, verbunden zu Beziehungen der betroffenen Tabellen, anstatt normalerweise als
Rechteck.
c) Rhomben Beziehungen entsprechen. Sie sind zu ihren betreffenden Tabellen mit Linien
verbunden, welche direkte oder indirekt Rhomben sein können. Die Sortierung von Tabellen in der
Liste von Beziehungen kann durch Numerierung angezeigt werden, obwohl die Sortierung nicht
relevant ist, es sei denn dieselbe Tabelle erscheint mehr als einmal in der Liste.
Beispiel 1.5: Die folgende Abbildung (a) zeigt ein einfaches ERD mit 3 Tabellen, EMPS, DEPTS und
MANAGERS. Die ersten beiden Tabellen stehen mittels ASSIGNED_TO in Verbindung, die zweite
und dritte mittels MANAGES (die Pfeilverbindungen werden vorerst ausgelassen). EMPS besitzt 3
Attribute, nämlich NAME, PHONE und SALARY, wobei NAME als Schlüssel verwendet wird. DEPTS
verwendet 2 Attribute, NAME und LOCATION, hingegen besitzt MANAGERS nur NAME.
In Abbildung (b) wird eine Beziehung mit PERSONS auf sich selbst über PARENT_OF dargestellt.
Die erste Verbindung zur einen Ecke beschreibt das Kind und die zweite Verbindung zur anderen
Ecke den zugehörigen Elternteil. Die Beziehung PARENT_OF beinhaltet Paare (p1, p2), so daß p2
als Elternteil von p1 erkannt werden kann.
3
Technische Datenorganisation
Alexander Stadlmann 4.HBa 1995/96
Beispiele für ERD´s
1.2.8 Funktionalität von Beziehungen
Bei einem Modell, das der Wirklichkeit entspricht ist es oft notwendig Beziehungen zu gruppieren,
gemäß wieviele Einheiten, Objekt von einer Tabelle, Einheitssatz mit wievielen Einheiten von einem
anderen Einheitssatz vereinigt werden können. Die einfachste und seltenste Form einer Beziehung
von zwei Sätzen ist die 1:1 Beziehung. Für jede Einheit in jedem Satz ist ein zugehöriges Mitglied in
einem anderen Satz vorhanden. Zum Beispiel die Beziehung MANAGES zwischen DEPTS und
MANAGERS, die Abbildung (a) könnte als 1:1 Beziehung bezeichnet werden. Ist dies der Fall, so
kann in der Datenbank nicht mehr als ein Manager pro Abteilung vorhanden sein oder eine Person
mehrere Abteilungen verwaltet. Es ist möglich, daß eine Abteilung zur Zeit keinen Manager besitzt
oder, daß ein Manager derzeit keine Abteilung zum Verwalten hat.
1.2.9 n:1 Beziehungen
In einer n:1Beziehung ist eine Einheit im Satz E2 mit 0 oder mehrere Einheiten in E1 verbunden, aber
jede Einheit in E1 ist mit höchstens einer Einheit in E2 verbunden. Diese Beziehung bedeutet n:1 (von
E1 nach E2). Zum Beispiel kann die Beziehung zwischen EMPS und DEPTS in Abbildung (a) als n:1
von EMPS zu DEPTS angesehen werden, so daß zu jeder Abteilung mehrere Mitarbeiter eingetragen
sind. Es ist auch möglich, wie z.B. der Präsident, einige Mitarbeiter bei keiner Abteilung eingetragen
sind.
1.2.10 m:n Beziehungen
Wir treten auch der m:n Beziehung entgegen, bei der es keine Einschränkung von k-fachen Einheiten
der Sätze gibt, die möglicherweise in einem Beziehungssatz erscheint. Zum Beispiel ist die Beziehung
PARENT_OF in obigen Abbildung eine m:n Beziehung, da wir zwei Elternteile zu jedem Kind finden
und umgekehrt zu jedem Elternteil mehrere Kinder vorhanden sein können. Die Beziehung der
Eintragung zwischen den Kursen und den Studenten ist noch ein Beispiel für eine m:n Beziehung, da
typisch, mehrere Studenten einen Kurs belegen können und mehrere Kurse von einem Studenten
belegt sein können.
Während m:n Beziehungen regelmäßig in der Praxis erscheinen, müssen wir vorsichtig sein wie diese
Beziehungen in einem begrifflichem Schema der aktuellen Datenbank zum Ausdruck gebracht werden.
Viele Datenmodelle erlauben keine direkte Darstellung von m:n Beziehungen, statt dessen ist es
nötig, daß die Beziehungen in einzelne n:1 Beziehungen zerlegt werden.
1.2.11 Anzeigen der Funktionalität bei ERD´s
In ERD´s verwenden wir Rhomben, bei der die Richtung mittels eines Pfeils angezeigt wird, um
wiederum anzuzeigen, wenn eine 1:1 oder 1:m Beziehung vorliegt. Anhand eines Beispiels nehmen
wir an, daß die Angestellten zu höchstens einer Abteilung zugewiesen sind, welche den Pfeil von
ASSIGNED_TO nach DEPTS in der obigen Abbildung erklärt.
1.3 Das relationale Datenmodell
Das relationale Modell stieg in seiner Bedeutung seit ihrer Ausstellung von E. Codd im Jahre 1970,
zu einem Punkt, wo es generell das Modell von der Auswahl für die Durchführung bzw. Verwendung
von neuen Datenbanken ist. Möglicherweise ist der wichtigste Grund für dessen Popularität der
wirksame Weg, den es, um einfache Sprachen mit welcher Operationen an Daten ausgedrückt
werden, unterstützt.
4
Technische Datenorganisation
Alexander Stadlmann 4.HBa 1995/96
1.3.1 Die „set-theoretic“ Vorstellung einer Relation
Das mathematische Konzept, das dem relationalen Modellen zugrunde liegt, ist die „set-theoretic
relation“, welche die „subset“ des kartesischen Produkts von einer Liste von Bereichen ist. Ein
Bereich ist hierbei einfach ein Satz von Werten, z.B. ist ein Satz von Integer-Werten ein Bereich.
5