Datenmodelle für Datenbanksysteme

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:

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. 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. "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. "Handeln mit m:n Beziehungen": Oft kommt es vor, dass 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, dass 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:

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, dass 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, dass zwei Länder nicht dieselbe Identifizierungsnummern verwenden, so dass 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, dass 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 dass 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 - Ebenen - Vorstellung einer Beziehung. Wenn eine Beziehung R unter Tabellen E₁, E₂, ..., E_k 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 (p₁, p₂), wo diese Person p₂ die Mutter von Person p₁ ist.
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, dass 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, dass aus der Beziehung ein eindeutiger Datensatz in der Zieltabelle folgt. Das muss 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:

Rechtecke Tabellen entsprechen 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. 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 dass p2 als Elternteil von p1 erkannt werden kann.






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, dass eine Abteilung zur Zeit keinen Manager besitzt oder, dass ein Manager derzeit keine Abteilung zum Verwalten hat.

1.2.9 n:1 Beziehungen

In einer n:1Beziehung ist eine Einheit im Satz E₂ mit 0 oder mehrere Einheiten in E₁ verbunden, aber jede Einheit in E₁ ist mit höchstens einer Einheit in E₂ verbunden. Diese Beziehung bedeutet n:1 (von E₁ nach E₂). Zum Beispiel kann die Beziehung zwischen EMPS und DEPTS in Abbildung (a) als n:1 von EMPS zu DEPTS angesehen werden, so dass 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, dass 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, dass 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.

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.

2074 Worte in "deutsch"  als "hilfreich"  bewertet