ISDA

1. externe Schicht: Anwendungsprogramme, Zugriff nur auf die relevanten Daten

2. konzeptionelle Schicht: Datenmodell

3. interne Schicht: hier liegen die Daten physisch mit den Zugriffspfaden

Daten sind Fakten; eine Sammlung von Zeichen mit Syntax, die eine digitale Representation von irgendeinem Aspekt der Welt ist. Eine Information wird daraus, wenn die Daten mit einer Semantik (= Bedeutung) belegt wird, also etwas ist, mit dem der Mensch etwas anfangen kann.

logisch zusammenhängende Daten -> Datenbank -> mit Semantik belegt -> Informationssystem

Die Datenbanken sind also die Grundlage eines Informationssystems.

Eine Datenbank ist eine logisch zusammenhängende Sammlung von Daten, die einen Ausschnitt der realen Welt beschreibt und füreinen bestimmten Zweck entworfen wird.

Eine Datenbank ist ein System zur elektronischen Datenverwaltung.

Ein Datenbankmodell ist ein Datenbankmanagementsystem (DBMS) und bildet die Grundlage für die Strukturierung von Daten.

Einige Arten sind:

• hierarchisch (nur Eltern-Kind-Bez. zwischen den Daten)

• objekt-orientiert (Daten können aus höheren Klassen “erben”)

• relational (Daten in Tabellen verwaltet; damit arbeiten wir)

Ein DBMS unterstützt das Datenmodell, verwaltet den Speicher und die Nutzer, bearbeitet Anfragen und stellt eine Anfragesprache bereit.

Beispiele für DBMS sind:

• Oracle

• PostGreSQL

• SQL-Server

DBMS werden von allen großen Softwaresystemen genutzt, z.B. von SAP.

die Kombination aus DBMS und der DB ergibt das Datenbankystem (DBS).

Das Entity-Relationship dient dazu, einen Ausschnitt der Welt darzustellen. Es besteht aus Entitys (= gleichwertige(s) Objekt(e) der realen oder nicht-realen Welt), Relationships (“ Beziehungen zwischen Entitys) und Attributen (= Eigenschaften der Entitys).

Es gilt als eine Grundlage für das Design einer relationalen Datenbank.

• Schlüsselattribut: identifiziert die Entity eindeutig (z.B. Matrikelnummer für Studenten)

• optionales Attribut: kein Schlüsselattribut

• abgeleitetes Attribut: Wert wird aus anderen Attributen berechnet (z.B. Alter aus Geburtsdatum)

• mengenwertiges Attribut: enthält mehrere Werte: z.B. Autor(en) für ein Buch, falls mehrere Personen das Buch geschrieben haben

• strukturiertes (zsm-gesetztes) Attribut: wird durch mehrere Attribute beschrieben; Wert entspricht der Verkettung der anderen Attribute (z.B. Adresse: besteht aus Straße, Hausnummer und PLZ)

Nebenbedingungen/einschränkungen:

1. Schlüsselattribut(e)

2. Referentielle Integrität: z.B. Kardinalitäten (1:n, n:m, 1:1 usw.)

3. Domänen: Einschränkung des Wertebereichs

4. Allg. Nebenbedingungen: z.B. nicht mehr als 20 Schauspieler pro Film

5. Länge eines Attributs (string mit xxx Zeichen)

6. Datentyp (Integer, string etc.)

Nebenbedingungen sind Teil des Schemas!

Schwache Entity-Typen haben keine Schlüsselattribute und sind deshalb von anderen Entity-Typen abhängig, die dann ein Schlüsselattribut haben, damit das Objekt aus der Entity eindeutig zugeordnet werden kann.

Beispiel:

1. Relationship/Beziehung: Raute

1. Schlüsselattribut: ausgefüllter Punkt

1. Entity: Rechteck

1. eine Totalität: schwarzer Punkt an einer oder beiden Seiten der Beziehung

1. schwache Entity-Typen: doppeltes Rechteck

Ein rekursiver Relationship-Typ ist eine Beziehung, die zwischen demselben Entity-Typen stattfindet. Z.B. ein FIlm, der ein VOrgänger von einem Film ist.

Bei rekursiven Relationship-Typen muss eine Richtung angegeben werden, z.B. so:

1. Generalisierung/Spezialisierung: Entity-Typen in Subklassen unterteilen; “ist_eine”-Beziheung. Beispiel (mit Notation):

1. Aggregation: Entity-Typen mithilfe von anderen Entity-Txpen beschreiben; “ist-Teil-von” oder “besteht_aus”-Beziehung. Beispiel (mit Notation):

1. total t: jeder Entity-Typ gehört einer Subklasse an

2. partiell p: Entity-Typ gehört nicht zwingend einer Subklasse an

3. überlappend o: Entity-Typen können mehreren Subklassen angehören

4. ausschließend d: Entity-Typen gehören nur einer Subklasse an

Ein Beispiel wäre das Fahrrad, welches aus einem Rahmen und den Rädern besteht.

1. Totalität: Ein Fahrrad ist nur ein Fahrrad, wenn es einen Rahmen hat. Daher wird bei dem Rahmen ein Punkt gesetzt, ähnlich wie hier:

1. Kardinalität: Ein Fahrrad besteht aus n Rädern, aber nur aus einem (1) Rahmen. Daher haben wir zwischen dem Fahrrad und dem Rahmen eine 1:1-Beziehung, zwischen den Rädern und dem Rad eine n:1-Beziehung (siehe oben).

1. Begriffsglossar (muss mit (2) übereinstimmen)

2. E-R-Modell

3. Protokoll (da können auch DInge drinstehen wie: “höchstens 10 Schauspieler pro Film”)

1. Namenskonflikte: Synonyme (Auto und KFZ) und Homonyme (Hahn, Schloss, Decke)

2. Typkonflikte: einmal als Entity-Typ und einmal als Attribut in versch. Teilschemata

3. Wertebereichskonflikte: z.B. Datum: 01/05/2023 oder 01-05-2023

4. Bedingungskonflikte: z.B. unterschiedliche Kardinalitäten oder Integritätsbedingungen

1. Treue zur Anwendung: realistisch modellieren!

2. keine Redundanz: keine Inkonsistenz

3. Einfachheit: nicht zu viele Enmtity-Typen und Relationship-Typen, id.R. reichen jeweils 7 +- 2

4. überlegte Entscheidung bei Entity-Typen und Attributen

5. sparsamer Einsatz von Relationships & schwachen Entity-Typen

1. Entity-Typen in Relationen umwandeln

2. Relationship-Typen in Relationen umwandeln

3. Zusammenlegen von Relationen

4. Sonderfälle für Generalisierungen beachten

Ein Relationales Modell besteht aus Relationsschemata (Tabellen), die jeweils aus dem Namen der Tabelle und deren Attributen bestehen. Das Schlüsselattribut ist hierbei ganz vorne.

Eine Zeile entspricht einer Entity, eine Spalte einem Attribut.

1. E/R-Stil: für jeden Entity-Typen der Hierarchie eine Relation mit Schlüsselattributen des Wurzel-Entity-Typs; Dopplungen können auftreten, aber nur Schlüsselattribute werden wiederholt

2. Objektorientierter Stil: elation für jeden Teilbaum -> erzeugt 2^n Relationen ABER minimaler Speicherbedarf, da es nur einen Tupel pro Entity gibt

3. mit Null-Werten: Eine einzige Relation mit Null-Werten bei den Attributen, die die Entity nicht besitzt; Tupel sind mitunter sehr lang