Daten, Informationen, Wissen und Objekte

Daten	Informationen	Wissen
Daten sind meist ohne Kontext Allgemeine Angaben (Zahlen-)Werte Formulierbare Befunde, die durch Messung oder Beobachtung gewonnen werden können „nackte Bits“	Daten, die in einen Kontext eingebettet sind Informationen entstehen aus interpretierten Daten Teilmenge an Wissen, das an Empfänger von Sender über ein Medium vermittelt wird	Gewinnung von „neuen“ Informationen, Wissen aus Vorhandenem

→ Die Grenzen verlaufen fließend

→ Die Sichtweise hängt oft von der Perspektive ab: Was aus einer Perspektive „nackte Daten“ sind, kann aus einer anderen Perspektive mit den dazugehörigen Kontextinformationen schon interpretierbar sein.

Einstieg Datenbanken

• Eine Datenbank kann praktisch alle Arten von Daten und Informationen speichern
• Datenobjekte (= modellierte Daten) –> Objekte der realen Welt werden in Datenbanken repräsentiert

Der Unterschied zwischen Informationen von Daten bei Informationssystemen

• Bei Datenbanken / Informationssystemen wird zwischen den Begriffen höchstens im speziellen Kontext (Datenmodell, Anwendung) präzisiert
• intuitiv:
  • Informationen ist ein Oberbegriff von Daten
  • Daten sind spezielle, einfache Informationen
  • Daten werden oft als atomar (unzerlegbar) angesehen
  • Aber: Es gibt auch komplexe (zerlegbare) Daten (z.B. Objekte)
  • Es gibt Informationen, die keine Daten sind, z.B. Gesetzmäßigkeiten, Kommentare, Zusammenhänge

Verwaltung von Datensätzen

• Verwalten heißt Bereitstellen von Operationen auf den Informations-Objekten, also z.B. speichern, wiederauffinden, hinzufügen, verändern, löschen etc.
• Die Wahl der Operation hängt von der gewählten Abstraktionsebene ab
  → Operationen müssen zu den Objekten „passen“

→ Ein Informationssystem ist also eine Implementierung eines Modells für Daten/Informationen/Wissen auf einer bestimmten Abstraktionsebene

Informationssysteme

Was sind Informationssysteme?

• Ein System, das große, gemeinsam benutzte Daten-/Informations-/Wissensmengen verwaltet
• Für eine ganze Reihe von Anwendungsprogrammen

Eigenschaften von Informationssystemen

• sicher, zuverlässig und verlässlich
• effizient und effektiv
• für Benutzer mit unterschiedlichen Anforderungen, Kenntnissen und Bedürfnissen

Ist Google ein Informationssystem?

→ nutzt Datenbanken, ist aber keine Datenbank (lässt keine komplexen Anfragen und Änderungen zu)

Relevante Aspekte von Datenbanken

Modellierung: Beschreibung der Information im System

Manipulation: Zugriffsmöglichkeiten auf die Daten

Fehlertoleranz: Garantien im Fall von „Crashes“

Effizienz: Performance

Datenbanken

Eine Datenbank ist zuständig für die langfristige Aufbewahrung von Daten, Sicherung vor Verlusten und Dienstleistung für mehrere Kunden (→ Effizienz)

Datenbank (DB): Strukturierter von DBMS verwalteter Datenbestand

Datenredundanz

Ohne Datenbanken kann es zur Datenredundanz kommen:

• Basis- oder Anwendungssoftware verwaltet ihre eigenen Daten in ihren eigenen (Datei-) Formaten, z.B. in Unternehmen:
• Daten sind redundant: mehrfach gespeichert

→ Probleme:

• • Verschwendung von Speicherplatz
  • Vergessen von Änderungen
  • keine zentrale, genormte Datenhaltung
  • keine effiziente Verarbeitung mehr möglich
  • mangelnder Datenschutz und Datensicherheit

Datenintegration

Mit Datenbanken wird Datenintegration gesichert

• gesamte Basis- und Anwendungssoftware arbeitet auf denselben Daten
  • effiziente Verwaltung großer Datenmengen
  • Paralleles Arbeiten auf Datenbanken
  • Gewährleistung von Datenschutz (kein unbefugter Zugriff) und Datensicherheit (kein ungewollter Datenverlust)

Datenbankmanagementsysteme (DBMS)

Software zur Verwaltung von Datenbanken

• verwaltet langfristig zu haltende Daten
• effiziente Verwaltung von großen Datenmengen
• alle Daten werden einheitlich beschrieben (→ Datenintegration)
• Operation und Sprache sind rein deskriptiv
• Datenschutz, Datenintegrität, Datensicherheit
• Datenbanksprache: SQL

Merke:

Datenbanksysteme (DBS)

Es wird unterschieden zwischen

1. generischen DBS: für beliebige Anwendungen gedacht und
2. spezifischen DBS: nur für spezielle Anwendungsfelder

Generische DBS werden meist nach unterstützten Datenmodellen klassifiziert:

1. relationale Datenbanken
2. objekt-orientierte Datenbanken
3. hieratische Datenbanken
4. Entity-Relationship-Datenbanken

Datenmodell:

→ Zusammenstellung bestimmter Konzepte zum Modellieren von Daten in der realen Welt und/oder im Rechner (z.B. Tabellen im relationalen Modell)

Datenbankmodell: Alternative Bezeichnung, wird selten gebraucht und suggeriert eher Modellierung der Datenstrukturen im Rechner

Grundprinzipien moderner Datenbanksysteme

System-Architekturen

• Beschreibung der Komponenten eines Datenbanksystems
• Standardisierung der Schnittstellen zwischen Komponenten
• 3-Ebenen-Architektur (ANSI-SPARC-Architektur)

• Fünf-Schichten-Architektur (beschreibt Transformationskomponenten im Detail)

9 Codd’sche Regeln

1. Integration: einheitliche, nichtredundante Verwaltung von Daten
2. Operationen: Speichern, Suchen, Ändern
3. Katalog: Zugriff auf Datenbankbeschreibungen im Data Dictionary
4. Benutzersichten: unterschiedliche Anwendungen benötigen eine unterschiedliche Sicht auf den Datenbestand
5. Integritätssicherung: Korrektheit des Datenbankinhalts
6. Datenschutz: Ausschluss unauthorisiereer Zugriffe
7. Transaktionen: Mehrere Datenbank-Operationen als Funktionseinheit
8. Synchronisation: Parallel ausgeführte Transaktionen koordinieren
9. Datensicherung: Wiederherstellung von Daten nach Systemfehlern

Klassifizierung der Komponenten

Definitionskomponenten	Datendefinition, Dateiorganisation, Sichtdefinition
Programmierkomponenten	DB-Programmierung mit eingebetteten DB-Operationen
Benutzerkomponenten	Anwendungsprogramme, Anfrage und Update interaktiv
Transformationskomponenten	Optimierung, Auswertung, Plattenzugriffssteuerung
Data Dictionary	Aufnahme der Daten aus Definitionskomponenten, Versorgung der anderen Komponenten

Schema-Architektur

Zusammenhang zwischen:

• Konzeptuellen Schemata (Ergebnis der Datendefinition)
• Internen Schemata (Festlegung der Dateiorganisationen und Zugriffspfade)
• Externen Schemata (Ergebnis der Sichtdefinition)
• Anwendungsprogrammen (Ergebnis der Anwendungsprogrammierung)

Ziele:

→ Trennung der semantischen Datensicht von der physischen Speicherung der Daten

→ Weitestgehende Datenunabhängigkeit der Anwendungsprogramme, d.h. Vermeidung von Abhängigkeiten zwischen Anwendungsprogramm und physischer Datenspeicherung

→  physische Speicherung kann ohne Programmänderung geändert werden

Schema versus Instanz

• Schema: Metadaten, Datenbeschreibungen
• Instanz: Anwenderdaten, Datenbankzustand oder -ausprägung

Datenbankschema besteht aus internen, konzeptuellen und externen Schemata und den Anwendungsprogrammen

→ im konzeptuellen Schema:

• Strukturbeschreibungen
• Integritätsbedingungen
• Autorisierungsregeln (pro Benutzer für erlaubte DB-Zugriffe)

Datenunabhängigkeit

• Stabilität der Benutzerschnittstelle gegen Änderungen
• physisch: Änderungen der Dateiorganisationen und Zugriffspfade haben keinen Einfluss auf das konzeptuelle Schema
• logisch: Änderungen am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme
• mögliche Auswirkungen von Änderungen am konzeptuellen Schema:

→ eventuell externe Schemata betroffen (z.B. Änderung der Attribute)

→ Anwendungsprogramme sind betroffen (Rekompilieren der Anwendungsprogramme, evtl. Änderung)

→ Nötige Änderungen werden aber vom DBMS erkannt und überwacht

Datenmodellierung

Modellierung einer kleinen Beispielanwendung

Architekturübersicht eines DBMS

Transaktionen

• Einheit der Verarbeitung im Mehrbenutzerbetrieb
  • Commit: erfolgreicher Abschluss
  • Abort: Abbruch
• zu synchronisierende Einheit im Mehrbenutzerbetrieb
• Einheit für Datenwiederherstellung (keine partiellen Effekte)

Einsatzgebiete

• Data Warehouse (Zentrale Datensammlung im Unternehmen, Zusammenführung von Daten aus verschiedenen Datenbanken z.B. verschiedener Unternehmensbereiche)

• Data Mining (Analyse / Untersuchung von Daten, um Zusammenhänge / Muster zu erkennen)

• OLAP, Online Analytical Processing (analytisches Informationssystem bzw. Methoden zur Datenanalyse, meist sehr komplexe Analysen: Stellung von Hypothese, OLAP Ergebnis = Analyse = Verifikation oder Widerlegung)

Entwicklungslinie (70er – 90er)

1. Relationale Datenbanksysteme
   • Daten in Tabellenstrukturen
   • 3-Ebenen-Konzept
   • Deklarative DML (= Data Manipulation Language)
   • Trennung zwischen DML und Programmiersprache
2. Wissensbanksysteme
   • Daten in Tabellenstrukturen
   • stark deklarative DML, integrierte Datenbankprogrammiersprache
3. Objektorientierte Datenbanksysteme
   • Daten in komplexeren Objektstrukturen (Trennung Objekt und seine Daten)
   • Deklarative oder navigierende DML
   • oft integrierte Datenbankkprogrammiersprache
   • oft keine vollständige Ebenentrennung

1. Relationale Datenbanken

• DB-Markt wird dominiert von DB-Systemen, die relationales Datenmodell unterstützen
• Führende Hersteller von relationalen DB-Produkten:
  • Oracle
  • Microsoft (Access, SQL Server)
  • IBM (DB2, Informix)
  • MySQL (Freeware)
  • Postgres (Freeware)
  • Software AG

• Relationale Datenbanken sind Sammlungen von Relationen
• Tabellen, die aus einzelnen Datensätzen bestehen, die alle dieselbe Feldstruktur aufweisen
• Motiviert durch das mathematische Konzept der Relation (ausschließlich diejenigen Beziehungen, bei denen klar ist, ob sie bestehen oder nich)

 

Legende:

Relationsschema	Fett geschriebene Zeilen
Relation	Tabelle (bei relationalen Datenbanken)
Tupel (Datensatz, Record)	Zeile der Tabelle, zusammenhängende Daten
Attribut	Spalte der Tabelle
Attributwert	Eintrag einer Zelle
Wertebereich	Mögliche Werte eines Attributs
Datenbankschema	Menge von Relationsschemata
Datenbank	Menge von Relationen

Spezifikation der Tabellen = Schema der relationalen Datenbank

Integritätsbedingungen

Schlüssel

• Attribute einer Spalte identifizieren eindeutig gespeicherte Tupel: Schlüsseleigenschaft
• z.B. MNr (musikernummer) für Tabelle Musiker
• Attributkombinationen können auch Schlüssel sein
• oft gekennzeichnet durch Unterstriche

→ Primärschlüssel (Primary Key)

• ein beim Datenbankentwurf ausgezeichneter Schlüssel

→ Fremdschlüssel (Foreign Key)

• Schlüssel einer Tabelle können in einer anderen (oder derselben) Tabelle als eindeutige Verweise genutzt werden → Fremdschlüssel, referenzielle Integrität
• z.B. MNr als Verweise auf Musiker
• Fremdschlüssel = Schlüssel in „fremder“ Tabelle

Bedingung:

• alle Attributwerte des Fremdschlüssels tauchen in der anderen Relation als Werte des Schlüssels auf

• Neben Primär- und Fremdschlüsseln können in SQL angegeben werden:
  • mit der default-Klausel Defaultwerte für Attribute
  • mit der create domain-Anweisung benutzerdefinierte Wertebereiche
  • mit der check-Klausel weitere lokale Integritätsbedingungen innerhalb der zu definierenden  Wertebereiche, Attribute und Relationsschemata

SQL – Structured Query Language

• am weitesten verbreitete relationale Datenbanksprache
• beinhaltet eine kostenlose Version
• Jedes relationale DBMS versteht SQL

Mögliche Wertebereiche in SQL

integer	für ganze Zahlen (ohne Nachkommastelle)
smallint	kleinere Ganzzahlen
decimal (p,q) und numeric (p,q)	für Zahlen mit Nachkommastelle
character (n) (kurz: char)	Zeichenketten mit fester Länge
character varying (kurz: varchar)	Zeichenketten variabler Länge
bit oder bit varying	analog für Bitfolgen
date, time bzw. timestamp	Datums-, Zeit- bzw. kombinierte Datums-Zeit-Angaben

Nullwerte

• not null = schließt bestimmte Spalten Nullwerte als Attributwerte aus
• Kennzeichnung von Nullwerte in SQL durch null —> ⊥
• null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nicht anwendbar“ oder „Wert existiert nicht“, gehört aber zu keinem Wertebereich
• null kann in allen Spalten auftauchen, außer in Schlüsselattributen und den mit not null gekennzeichneten

Anfrageoperationen auf Tabellen

• Basisoperationen —> erlauben Berechnungen von neuen Ergebnistabellen aus gespeicherten Datenbanktabellen
• Operationen = Relationsalgebra

→ für Datenbankanfragen entsprechen die Inhalte der Datenbank den Werten, Operationen sind dagegen Funktionen zum Berechnen der Anfrageergebnisse

Anfrageoperationen sind beliebig kombinierbar und bilden eine Algebra zum „Rechnen mit Tabellen“ → Relationsalgebra

Selektion

• Auswahl von Zeilen einer Tabelle anhand eines Selektionsprädikats

Projektion

• Auswahl von Spalten durch Angabe einer Attributliste
• entfernt doppelte Tupel

Natürlicher Verbund

• Verbund → verknüpft Tabellen über gleichbenannte Spalten, indem er zwei Tupel verschmilzt, falls sie dort gleiche Werte aufweisen

• Tupel die keinen Partner finden (dangling tuples), werden eliminiert
• Umbenennung → Anpassung von Attributnamen

Mengenoperationen

• Vereinigung r₁ ∪ r₂  von zwei Relationen
• sammelt die Tupelmenge zweier Relationen unter einem gemeinsamen Schema auf
• Attributmengen der Relationen müssen identisch sein

• Differenz r₁ – r₂ eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen

• Durchschnitt r₁ ∩ r₂ gibt die Tupel aus, die in beiden Relationen gemeinsam vorkommen

SQL Software

• XAMPP: Paket zur einfachen Installation diverser Software inkl. MySQL, Apache Webserver, PHP

XAMPP-Anleitung:

1. XAMPP Control Panel öffnen
2. Apache und MySQL starten
3. Seite im Browser öffnen
4. auf „PhpMyAdmin“ klicken
5. Öffnung der Seite um Datenbanken zu erstellen
6. Auf SQL kann man die Befehle eingeben, um eine Datenbank zu erstellen

 

SQL Grundbegriffe

• SQL setzt sich aus zwei Teilsprachen zusammen
  • einer Datendefinitionssprache („data definition language“ DDL)
  • einer Datenmanipulationssprache („data manipulation language“ DML)

• DDL enthält die Befehlsformate, mit denen man Datenbankschemata definieren und manipulieren kann (Schemaevolution)
• DML enthält Befehle zum Formulieren von Anfragen und Änderungen von Datenbankzuständen
• Gerüst jedes SQL-Befehls besteht aus englischen Schlüssenwörtern, z.B. SELECT, FROM, CREATE oder WHERE

→ Schlüsselworte sind „reserviert“ und dürfen nur zu diesem Zweck verwendet werden.

Verschiedene Objekte in SQL

Tabelle	table
Spalte	column
Zeile	row
Wertebereich	Wertebereich

Erzeugung von Tabellen

Erzeugung von Tabellen = Erzeugen der Datenbankschemata

1. Erzeugung der Datenbank

• • create database Datenbankenname
  • use Datenbankenname

2. Erzeugung von Tabellen / Relationen

• • create table Tabellenname

Beispiel für create table

Musiker und Alben:

SQL: create table

1. Zuerst muss eine neue Datenbank für die Übung erstellt werden (create database Is2017)
2. Als nächstes müssen die Tabellen für die Musiker und für die Alben erstellt werden
3. Dabei ist der Primarykey jeweils die Musikernummer (MNr) und die Albumnummer (ANr)

erste Tabelle

create database Is2017

create table Musiker (

MNr int primary key,

Name varchar (20),

Land varchar (30));

zweite Tabelle

create table Album (

ANr int primary key,

Titel varchar(50) not null,

Jahr int not null,

Genre varchar(10),

Preis decimal (6,2),

MNr int,

foreign key (MNr)

references Musiker (MNr));

—> Der foreign key kennzeichnet hierbei Spalte als Fremdschlüssel

Daten in Datenbank laden – Insert

insert-Anweisung

• optionale Attributliste ermöglicht das Einfügen von unvollständigen Tupeln

insert-Beispiele

SQL Anfragen

SQL: select

Auswahl von Tabellen: die from-Klausel

• einfachste Form:
• hinter jedem Relationennamen kann optional eine Tupelvariable stehen

Kartesisches Produkt

• bei mehr als einer Relation wird das kartesische Produkt gebildet
• alle Kombinationen werden ausgegeben

Natürlicher Verbund in SQL92

• frühe SQL-Versionen
  • üblicherweise realisierter Standard in aktuellen Systemen
  • kennen nur Kreuzprodukt, keinen expliziten Verbundoperator
  • Verbund durch Prädikat where

Tupelvariablen und Relationennamen

• Anfrage

• ist äquivalent zu

Präfixe für Eindeutigkeit

• Attribut Mir existiert sowohl in der Tabelle Album als auch in Musiker, deshalb muss es mit Präfix geschrieben werden:

Tupelvariablen für mehrfachen Zugriff

• Einführung von Tupelvariablen erlaubt mehrfachen Zugriff auf eine Relation:

• Spalten lauten dann:

Tupelvariablen für Eindeutigkeit

• bei der Verwendung von Tupelvariablen, kann der Name einer Tupelvariablen zur Qualifizierung eines Attributs benutzt werden:

Die where-Klausel

• Formen der Bedingung:

• • vergleich eines Attributs mit einer Konstanten:

attribut ⩉ konstante

• • Vergleich zwischen zwei Attributen mit kompatiblen Wertebereichen:

attribut ⩉ attribut 2

• logische Konnektoren or, and und  not

Verbundbedingungen

• Verbundbedingung hat die Form:

Schachtelung von Anfragen

• für Vergleiche mit Wertemenge notwendig:

• • Standardvergleiche in Verbindung mit den Quantoren all (⩝) oder any (∋)
  • spezielle Prädikate für den Zugriff auf Mengen, in und exists

Beispiel

• not in kann für Bildung von Differenzen verwendet werden, z.B. für die Anfrage „Musiker ohne Album“

Bereichsselektion

• schränkt damit Attributwerte auf das abgeschlossene Intervall [konstante1, konstante2]

Skalare Ausdrücke

• skalare Operationen auf

• • numerischen Wertebereichen: etwa +, -, * und /
  • Strings: Operationen wie char_lenght (aktuelle Länge eines Strings), die Konkatenation II und die Operation substring  (Suchen einer Teilzeichenkette an bestimmten Positionen der Strings)
  • Datumstypen und Zeitintervalle: Operationen wie current_date (aktuelles Datum), current_time (aktuelle Zeit), +, – und *

Sortierung mit Order by 

• Sortierung aufsteigend (asc) oder absteigend (desc)
• Sortierung als letzte Operation einer Anfrage —> Sortierattribut muss in der select-Klausel vorkommen

Behandlung von Nullwerten

• skalare Ausdrücke: Ergebnis null, sobald Nullwert in die Berechnung eingeht
• in allen Aggregatfunktionen bis auf count (*) werden Nullwerte vor Anwendung der Funktion entfernt
• fast alle Vergleiche mit Nullwert ergeben Wahrheitswert unknown (statt true oder false)
• Ausnahme: is null ergibt true, ist not null ergibt false

SQL: Sichten

Sichten

= virtuelle Relationen (bzw. virtuelle Datenbankobjekte in anderen Datenmodellen —> engl. view)

• Sichten sind externe DB-Schemata folgend der 3-Ebenen-Schemaarchitektur
• Definition

• • Relationsschema (implizit oder explizit)
  • Berechnungsvorschrift für virtuelle Relation, etwa SQL-Anfrage

Vorteile

• Vereinfachung von Anfragen für den Benutzer der Datenbank
• Möglichkeit der Strukturierung der Datenbankbeschreibung, zugeschnitten auf Benutzerklassen
• logische Datenunabhängigkeit —> Stabilität der Schnittstelle für Anwendungen gegenüber Änderungen der Datenbankstruktur
• Beschränkung von Zugriffen auf eine Datenbank im Zusammenhang mit der Zugrifffskontrolle

Probleme

• automatische Anfragetransformation
• Durchführung von Änderungen auf Sichten

Definition von Sichten in SQL

Kriterien für Änderungen auf Sichten

• Effektkonformität

• • Benutzer sieht Effekt als wäre die Änderung auf der Sichtrelation direkt ausgeführt worden

• Minimalität

• • Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten

• Konsistenzerhaltung

• • Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen

• Respektierung des Datenschutzes

• • Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht betroffen werden

Projektionssicht

Datenbank Entwurf

Wie spezifiziere ich bei einer bestimmten Anwendung die „richtigen“ Tabellen?

 Schritt 1: Modellbildung der realen Welt

 

Schritt 1: Das Entity-Relationship-Modell

Entity: Objekt der realen Welt oder Objekt aus der Vorstellungswelt, auch: Datenobjekt oder Informationsobjekt

—> Beispiele: Produkte, Personen, Musiker, auch Informationen über Ereignisse: Bestellung,  Vorlesung,..

Relationship: Beziehung zwischen Entities

—> Beispiele: Musiker produziert Album, Dozent hält Vorlesung, Kunde bestellt Produkt…

Attribut: Eigenschaften von Entities und Beziehungen

—> Beispiele: Name des Studierenden, Titel der Vorlesung

Beziehungstypen

1 : 1 Beziehung

• Jedem Element vom Entity-Typ 1ist maximal ein Element von Entity-Typ 2 zugeordnet und umgekehrt
• Beispiele: Frau ist verheiratet mit Mann, Hauptstadt von Bundesland

1 : N Beziehung

• Jedem Element vom Entity-Typ 1 sind beliebig viele Elemente von Entity-Typ 2 zugeordnet und zu jedem Element von Entity-Typ 2 gibt es maximal ein Element von Entity-Typ 1
• Beispiel: Mutter hat Kinder, Lieferant liefert Produkt

N : 1 Beziehung

• umgekehrt zu 1 : N, auch funktionale Beziehung
• zweistellige Beziehungen, die eine Funktion beschreiben:

Jedem Entity eines Entity-Typs E₁ wird maximal ein Entity eines Entity-Typs E₂ zugeordnet

N : M Beziehung

• jedem Element vom Entity-Typ 1 sind beliebig viele Elemente von Entity-Typ 2 zugeordnet und umgekehrt = keine Einschränkung
• Beispiel: Bestellung beinhaltet Produkte

Kardinalitäten

 

Schritt 2: Umsetzung des konzeptionellen Schemas in das Datenbankschema

= Abbildung des Entity-Relationship-Modells in relationales Modell

= Umsetzung in Tabellenspezifikation

Abbildung der

• Entities und Beziehungen auf Relationenschema = Tabellen
• Attribute auf Attribute des Relationsenschema = Spaltennamen
• Schlüssel bei Entity-Typen werden übernommen
• Schlüssel bei Beziehungen werden wie folgt festgelegt:

1:1-Beziehung —> einer der beiden Schlüssel wird Primärschlüssel

1:N-Beziehung —> Schlüssel der N-Seite wird Primärschlüssel

N:M-Beziehung —> beide Schlüssel werden zusammen Primärschlüssel

Datenbankentwurf: Entwurfsaufgabe

• Datenerhaltung für mehrere Anwendungssysteme und mehrere Jahre
• daher: besondere Bedeutung
• Anforderungen an Entwurf

• • Anwendungsdaten jeder Anwendung sollen aus Daten der Datenbank ableitbar sein (und zwar möglichst effizient)
  • nur „vernünftige“ (wirklich benötigte) Daten sollen gespeichert werden
  • nicht-redundante Speicherung

Phasenmodell

Datenbankentwurf: Anforderungsanalyse

• Vorgehensweise:

• • Sammlung des Informationsbedarfs in den Fachabteilungen

• Ergebnis:

• • informale Beschreibung (Texte, tabellarische Aufstellungen, Formblätter) des Fachproblems
  • Trennen der Information über Daten (Datenanalyse) von den Information über Funktionen (Funktionsanalyse)

• „Klassischer“ DB-Entwurf:

• • nur Datenanalyse und Folgeschritte

• Funktionsentwurf:

• • siehe Methoden des Software Engineering

Datenbankentwurf: Konzeptioneller Entwurf

• erste formale Beschreibung des Fachproblems
• Sprachmittel: semantisches Datenmodell
• Vorgehensweise:

• • Modellierung von Sichten z.B. für verschiedene Fachabteilungen
  • Analyse der vorliegenden Sichten in Bezug auf Konflikte
  • Integration der Sichten in ein Gesamtschema

• Ergebnis: konzeptionelles Gesamtschema, z.B. (E)ER-Diagramm

Datenbankentwurf: Datenbankmodell

• Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken
• Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest
• Datenbankbeschreibungen = Datenbankschemata

Ein Datenbankmodell legt fest…

1. statistische Eigenschaften

• • Objekte
  • Beziehungen

→ inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können

2. dynamische Eigenschaften wie

• • Operationen
  • Beziehungen zwischen Operationen

3. Integritätsbedingungen an

• • Objekte
  • Operationen

• Klassische Datenbankmodelle sind speziell geeignet für

• • große Informationsmengen mit relativ starrer Struktur und
  • die Darstellung statistischer Eigenschaften und Integritätsbedingungen (–> Bereiche 1 (a), 1 (b), und 3 (a))

• Entwurfsmodelle: (E)ER-Modell, UML,…
• Realisierungsmodelle: Relationenmodell, objektorientierte Modelle

Datenbankentwurf: ER-Beispiel

Datenbankentwurf: ER-Modell – Werte

• Werte: primitive Datenelemente, die direkt darstellbar sind
• Wertemengen sind beschrieben durch Datentypen, die neben eine Wertemenge auch die Grundoperationen auf diesen Werten charakterisieren
• ER-Modell: vorgegebene Standard-Datentypen, etwa die ganzen Zahlen int, die Zeichenketten string, Datumswerte date etc.
• jeder Datentyp stellt Wertebereich mit Operationen und Prädikaten dar

Datenbankentwurf: ER-Modell – Entities

• Entities sind die in einer Datenbank zu repräsentierenden Informationseinheiten
• im Gegensatz zu Werten nicht direkt darstellbar, sondern nur über ihre Eigenschaften beobachtbar
• Entities sind eingeteilt in Entity-Typen, etwa E₁, E₂… (z.B. Album oder Musiker)
• Menge der aktuellen Entities:

𝛔(E₁) = {e₁, e₂, …, e_n}

Datenbankentwurf: ER-Modell – Attribute

• Attribute modellieren Eigenschaften von Entities oder auch Beziehungen
• alle Entities eines Entity.Typs haben dieselben Arten von Eigenschaften; Attribute werden somit für Entity-Typen deklariert
• Beispiel:

• textuelle Notation E(A₁ : D₁, …, A_m : D_m)

Datenbankentwurf: ER-Modell – Schlüssel

Identifizierung durch Schlüssel

• Schlüsselattribute: Teilmenge der gesamten Attribute eines Entity-Typs E(A₁…., A_m)

{S₁,….,S_k} ⊆ {A₁,….,A_m}

• in jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des Entity-Typs E
• bei mehreren möglichen Schlüsselkandidaten: Auswahl eines Primärschlüssels
• Notation: markieren durch Unterstreichung

E(…,S₁,…,S-i,…)

Datenbankentwurf: ER-Modell – Beziehungstypen

• Beziehungen zwischen Entities werden zu Beziehungstypen zusammengefasst
• allgemein: beliebige Anzahl n ≥ 2 von Entity-Typen kann an einem Beziehungstyp teilhaben
• zu jedem n-stelligen Beziehungstyp R gehören n Entity-Typen

E₁…..E_n 

• Ausprägung eines Beziehungstyps

𝛔(R) ⊆𝛔(E₁) x 𝛔 (E₂) x … x 𝛔 (E_n)

• Notation

• textuelle Notation: R (E₁, E₂, …, E_n)
• wenn Entity-Typ mehrfach an einem Beziehungstyp beteiligt:
• Vergabe von Rollennamen möglich

—> verheiratet (Frau: Person, Mann: Person)

Datenbankentwurf: ER-Modell – Beziehungsattribute

• Beziehungen können ebenfalls Attribute besitzen
• Attributdeklarationen werden beim Beziehungstyp vorgenommen; gilt auch hier für alle Ausprägungen eines Beziehungstyps —> Beziehungsattribute

• textuelle Notation: R(E₁,…,E_n;A₁,…,A_k)

Datenbankentwurf: ER-Modell – Merkmale von Beziehungen

• Stetigkeit oder Grad:

• • Anzahl der beteiligten Entity-Typen
  • häufig: binär
  • Beispiel: Lieferant liefert Produkt

• Kardinalität oder Funktionalität:

• Anzahl der eingehenden Instanzen eines Entity-Typs
• Formen 1:1, 1:n, m:n
• stellt Integritätsbedingun dar
• Beispiel: maximal 5 Produkte pro Bestellung

 

Zwei- vs. mehrstellige Beziehungen

Beispiele:

Datenbankentwurf: ER-Modell – [min,max]-Notation

• schränkt die möglichen Teilnahmen von Instanzen der beteiligten Entity-Typen an der Beziehung ein, indem ein minimaler und ein maximaler Wert vorgegeben wird
• Notation für Kardinalitätsangaben an einem Beziehungstyp

R (E₁,…,E_i [min_i, max_i],…,E_n)

• Kardinalitätsbedingung: min_i ≤  |{r | r  ∈ R ⋀ r.E_i = e_i} | ≤ max_i
• Spezielle Wertangaben für max_i ist *

Datenbankentwurf: ER-Modell – Kardinalitätsangaben

• [0, *] legt keine Einschränkung fest (default)
• R(E₁ [0, 1], E₂) entspricht einer (partiellen) funktionalen Beziehung

R : E₁ —> E₂, da jede Instanz aus E maximal einer Instanz aus E₂ zugeordnet ist

• totale funktionale Beziehung wird durch R(E₁ [1, 1], E₂) modelliert

Beispiele:

• partielle funktionale Beziehung

lagert_in (Produkt [0, 1], Fach [0, 3]

„Jedes Produkt ist im Lager in einem Fach abgelegt, allerdings wird ausverkauften, bzw. gegenwärtig nicht lieferbaren Produkte kein Fach zugeordnet. Pro Fach können maximal drei Produkte gelagert werden.“

• totale funktionale Beziehung

liefert (Lieferant [0, *], Produkt [1, 1])

„Jedes Produkt wird durch genau einen Lieferant geliefert, aber ein Lieferant kann durchaus mehrere Produkte liefern.“

Datenbankentwurf: ER-Modell – Abhängige Entity-Typen

• abhängiger Entity-Typ: Identifikation über funktionale Beziehung

• Abhängige Entities im ER-Modell: Funktionale Beziehung als Schlüssel

Datenbankentwurf: ER-Modell – Abhängige Entity-Typen 2

• Mögliche Ausprägung für abhängige Entities

Datenbankentwurf: ER-Modell – IST-Beziehung

• Spezialisierungs-/Generalisierungsbeziehung oder auch IST-Beziehung
• textuelle Notation: E₁ IST E₂
• IST-Beziehung entsprich semantisch einer injektiven funktionalen Beziehung

Datenbankentwurf: ER-Modell – IST-Beziehung Eigenschaften

• Jeder Album-Instanz ist genau eine Produkt-Instanz zugeordnet

—> Album-Instanzen werden durch die funktionale IST-Beziehung identifiziert

• nicht jedes Produkt ist zugleich ein Album (z.B. Single, Film,…)
• Attribute des ENtity-Typs Produkt treffen auch auf Alben zu: „vererbte“ Attribute

Album (Produkt , Titel, Preis, Genre, Laufzeit) 

von Produkt

• nicht nur die Attributdeklarationen vererben sich, sondern auch jeweils die aktuellen Werte für eine Instanz

Datenbankentwurf: ER-Modell – IST-Beziehung: Alternative Notation

Datenbankentwurf: ER-Modell – IST-Beziehung: Kardinalitätsangaben

• für jede Beziehung E₁ IST E₂ gilt immer: IST (E₁ [1, 1], E₂ [0, 1])
• Jede Instanz von E₁ nimmt genau einmal an der IST-Beziehung teil, während Instanzen des Obertyps E₂ nicht teilnehmen müssen
• Aspekte wie Attributvererbung werden hiervon nicht erfasst

Datenbankentwurf: ER-Modell – Optionalität von Attributen

Datenbankentwurf: ER-Modell – Weitere Konzepte

• Strukturierte Attributwerte im ER-Modell

Datenbankentwurf: Vorgehen

• ER-Modellierung von verschiedenen Sichten auf Gesamtinformation, z.B. für verschiedene Fachabteilungen eines Unternehmen —> konzeptueller Entwurf

• • Analyse und Integration der Sichten
  • Ergebnis: konzeptionelles Gesamtschema

• Verteilungsentwurf bei verteilter Speicherung
• Abbildung auf konkretes Implementierungsmodell (z.B. Relationenmodell) —> logischer Entwurf
• Datendefinition, Implementierung und Wartung —> physischer Entwurf

Datenbankentwurf: ER-Abbildung

• Entity-Typen und Beziehungstypen: jeweils auf Relationenschemate
• Attribute: Attribute des Relationenschemas, Schlüssel werden übernommen
• Kardinalitäten der Beziehungen: durch Wahl der Schlüssel bei den zugehörigen Relationenschemata ausdrücken
• in einigen Fällen: Verschmelzen der Relationenschemata von Entity-Beziehungstypen
• zwischen den verbleibenden Relationenschemata diverse Fremdschlüsselbedingungen einführen

Abbildung von Beziehungstypen

• neues Relationenschema mit allen Attributen des Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der beteiligten Entity-Typen
• Festlegung der Schlüssel:

• m:n – Beziehung: —> beide Primärschlüssel zusammen werden Schlüssel im neuen Relationenschema
• 1:n – Beziehung: Primärschlüssel der n-Seite (bei der funktionalen Notation die Seite ohne Pfeilspitze) wird Schlüssel im neuen Relationenschema
• 1:1 – Beziehung: beide Primärschlüssel werden je ein Schlüssel im neuen Relationenschema, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt

n:m-Beziehungen

• Umsetzung

Bestellung (BestellNr, Datum)

Produkt (ProdNr, Bezeichnung, Preis)

Umfasst (BestellNr —> Bestellung, ProdNr —> Produkt, Menge)

• Attribute BestellNr und ProdNr sind gemeinsam Schlüssel

1:n-Beziehungen

• Umsetzung (zunächst)

Album (AlbumNr, Titel, Preis)

Musiker (MNr, Name, Land)

EingespieltVon (AlbumNr, MNr)

Abhängige Entity-Typen

• Umsetzung

Bestellposition (PosNr, BestNr —> Bestellung, Menge, Produkt)

Bestellung (BestNr, Datum)

Mögliche Verschmelzung

• optionale Beziehungen ([0, 1] oder [0, n]) werden nicht verschmolzen
• bei Kardinalitäten [1,1] oder [1, n] (zwingende Beziehungen) Verschmelzung möglich:

• • 1:n – Beziehung: das Entity-Relationenschema der n-Seite kann in das Relationenschema der Beziehung integriert werden
  • 1:1 – Beziehung: beide Entity-Relationenschemata können in das Relationenschema der Beziehung integriert werden

Verschmelzung bei 1:n – Beziehung

• da Album von einem Musiker/Band eingespielt werden muss (zwingende Beziehung), können Relationenschemata Album und EingespieltVon verschmolzen werden
• Umsetzung

Album (AlbumNr, Titel, Preis,

Mir —> Musiker)

Musiker (MNr, Name, Land)

1:1 – Beziehung

Standardumsetzung (ohne Verschmelzung):

Album (AlbumNr, Titel, Laufzeit)

DVDVideo (ProdNr, Format, Titel)

Gehört_Zu (AlbumNr —> Album, ProdNr —> DVDVideo)

• Umsetzung mit Verschmelzung

• Effekt bei „unechter“ 1:1-Beziehung

IST-Beziehung

• Umsetzung

Produkt (ProdNr, Titel, Preis)

Album (ProdNr —> Produkt,

Genre, Laufzeit )

Buch (ProdNr —> Produkt, ISBN, Verlag)

Mehrstellige Beziehungen

• jeder beteiligte Entity-Typ wird nach den obigen Regeln behandelt
• für Beziehung Bestellt werden Primärschlüssel der drei beteiligten Entity-Typen in das resultierende Relationenschema aufgenommen
• Beziehung ist allgemeiner Art (k:m:n – Beziehung): alle Primärschlüssel bilden zusammen den Schlüssel

Übersicht über die Transformationen

Normalformen

Funktionale Abhängigkeiten

• funktionale Abhängigkeiten zwischen Attributmengen X und Y einer Relation

—> Wenn in jedem Tupel der Relation der Attributwert unter den X-Komponenten den Attributwert unter den Y-Komponenten festlegt

• Unterscheiden sich zwei Tupel in den X-Attributen nicht, so haben sie auch gleiche Werte für alle Y-Attribute
• Notation für funktionale Abhängigkeiten (FD —> funktional dependency): X —>Y
• Beispiel:

AlbumNr —> Titel, MNr, Name

MNr       —> Land

Schlüssel als Spezialfall

• Für Beispiel

AlbumNr —> Titel, Jahr, Genre, MNr, Name, Land

• Immer: AlbumNr —> AlbumNr, dann gesamtes Schema auf rechter Seite
• Wenn linke Seite minimal: Schlüssel
• Formal: Schlüssel X liegt vor, wenn für Relationenschema R FD

X —> R gilt und X minimal

Ziel des Datenbankentwurfs —> alle gegebenen funktionalen Abhängigkeiten in „Schlüsselabhängigkeiten“ umformen, ohne dabei semantische Information zu verlieren

Schemaeigenschaften

• Relationenschamata, Schlüssel und Fremdschlüssel so wählen, dass

1. alle Anwendungsdaten aus den Basisrelationen hergeleitet werden können
2. nur semantisch sinnvolle und konsistente Anwendungsdaten dargestellt werden können
3. die Anwendungsdaten möglichst nicht-redundant dargestellt werden

• Hier: Forderung 3

• • Redundanzen innerhalb einer Relation: Normalformen
  • globale Redundanzen: Minimalität

Normalisierung

• legen Eigenschaften von Relationenschemata fest
• verbieten bestimmte Kombinationen von funktionalen Abhängigkeiten in Relationen
• sollen Redundanzen und Anomalien vermeiden

Erste Normalform

• erlaubt nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer oder string erlaubt, aber keine Konstruktiven wie array  oder set 

Zweite Normalform

• partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon von einem Teil des Schlüssels abhängt
• Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen

Beispiel:

Eliminierung partieller Abhängigkeiten

Zur Erreichung der 2. Normalform: Zerlegung (Dekomposition) der Relationen

Kriterien:

Verlustlosigkeit (= Verbundtreue)	Abhängigkeitserhaltung (= Abhängigkeitstreue)
Relationenschemata müssen teilweise in kleinere Relationenschemata zerlegt werde, damit die Kriterien der Normalformen erfüllt werden —> bedeutet, dass die Originalrelation wieder aus den zerlegten Relationen mit dem natürlichen Verbund zurückgewonnen werden kann	eine Menge von Abhängigkeiten aus der alten Tabelle müssen auf das neue Schema übertragbar sein —> in die Menge der Schlüsselabhängigkeiten, da diese vom Datenbanksystem effizient überprüft werden —> äquivalent zu Schlüsselabhängigkeiten —> abhängigkeitstreu

Verbundtreue Dekomposition

–> es besteht eine funktionale Abhängigkeit zwischen B und C

ABER es kann auch passieren, dass eine Zerlegung nicht verbundtreu ist und zwar dann, wenn keine funktionale Abhängigkeit vorliegt

Nicht verbundtreue Dekomposition

Dritte Normalform

• eliminiert transitive Abhängigkeiten
• 3 NF betrachtet nur Nicht-Schlüsselattribute als Endprodukt transitiver Abhängigkeiten

Eliminierung transitiver Abhängigkeiten

Boxe-Codd-Normalform

• Verschärfung der 3 NF —> Eliminierung transitiver Abhängigkeiten auch zwischen Primattributen
• BCNF kann jedoch Abhängigkeitstreue verletzen

Minimalität

• Global Redundanzen vermeiden
• andere Kriterien mit möglichst wenig Schemata erreichen

Schemaeigenschaften

Übungen

Musiker-Übung

Vorgehen:

1.Erstellen einer Neune Datenbank mit create database

2. Erstellen der Tabellen „Musiker“ und „Album“ mit create table

—> Dabei ist jeweils die Musiker Nummer (MNr) und die Album Nummer (ANr) primary key

—> der foreign key bei „Album“ kennzeichnet den Fremdschlüssel (Primärschlüssel von „Musiker“)

3. Nun werden die beiden Tabellen mit Attributwerten gefüllt

4. Natürlicher Verbund der beiden Tabellen

5. Führen Sie folgende Aktionen durch

Projektion: Lassen Sie sich die Liste aller Musikernamen anzeigen

Selektion: Lassen Sie sich alle Albendatensätze (=Zeilen) aus dem Jahr 2014 anzeigen

Lassen Sie sich alle Musiker aus England auflisten

Kombinieren Sie in einer Anfrage auf beide Tabellen eine Bedingung (where…) auf dem Preis mit einer Bedingung auf das Land, und lassen Sie sich Titel, Musikername, Jahr, Preis und Land anzeigen

Restaurant-Übung

Vorgehen

1. In einer Datenbank sollen die Restaurantvorlieben von Studierenden erfasst werden. Jedes Restaurant hat eine Rest.nummer (RNR, Primärschlüssel), einen Namen, einen Inhaber sowie PLZ, Ort und Straße. Zu den Studierenden werden Matrikelnummer (MNR, Primärschlüssel), Name, Vorname, Alter und der Studiengang verwaltet.

2. Erzeugen sie eine dritte Tabelle STUDIREST (keineUmlaute/Sonderzeichen), in der erfasst wird, welche Studierende (Matrikelnummer) welches Restaurant (RNR) bevorzugen! Nehmen Sie hier SRNR (Studi-Rest-Nummer) als Primärschlüssel und geben sie gegebenenfalls den Fremdschlüssel an.

3.  Füllen Sie die Tabellen RESTAURANT und STUDENT per SQL Anweisung mit mindestens 7 Studenten und 5 Restaurants. Füllen Sie die Tabelle STUDI-REST mit den fünf Lieblingsrestaurants der sieben Studierenden, dabei soll ein Restaurant das Lieblingsrestaurant von mindestens 3 Studierenden sein, und 2 Studierende sollten mindestens 2 Lieblingsrestaurants haben und ein Restaurant soll von Niemanden bevorzugt werden.

Beispiel Essen gehen mit Freudinnen:

4. Führen Sie den Verbund der Tabellen STUDENT und STUDI-REST durch, und geben Sie das SQL Kommando (select …) dazu an.

5. Nennen wir die Ergebnistabelle von Aufgabe 4 STUDENT-REST. Führen Sie den Verbund der Tabellen STUDENT-REST und RESTAURANT durch und geben Sie das SQL Kommando dazu an.

Zug Übung (Entity-Relationship-Modell)

Entities	Bahnhof Stadt Zug
Attribute	Bahnhof Stadtname Bahnhofnummer Straße Postleitzahl Stadt Stadtnummer Stadtname Bundesland Zug Zugnummer Wagons
Relations	Start Ziel verbindet Abfahrt Ankunft liegt in

Vorgehen

1.Erzeugen einer Datenbank für Zugverbindungen

2. Erzeugen der Tabellen für das Relationenschema

Beziehungstypen:

1 : N Beispiele

—> Ein Bahnhof kann nur in einer Stadt liegen, ABER eine Stadt kann mehrere Bahnhöfe haben

—> Ein Zug kann nur in einem Bahnhof starten, ABER aus einem Bahnhof können mehrere Züge starten

N : 1 Beispiele

—> Ein Zug kann nur in einem Bahnhof ankommen, ABER in einem Bahnhof können auch mehrere Züge ankommen

N : M Beispiele

—> In einem Bahnhof können mehrere Züge An- und Abfahren UND ein Zug kann in mehreren Bahnhöfen An- und Abfahren

Füllen der Tabellen und Anzeigen lassen der eingegebenen Tabellen

—> Bahnhöfe: mindestens 6 Einträge

—> Städte: mindestens 5 Einträge,

—> Züge: mindestens 6 Einträge

—> verbindet: mindestens 18 Einträge, entsprechend ergänzen mit Abfahrtszeit & Ankunftszeit, Abfahrts- und Ankunftsgleis

Für einen Bahnhof lassen Sie sich einen Fahrplan anzeigen (z.B. Abfahtsfahrplan des Bahnhofs).

—> Abfahrtsplan der Züge aus Frankfurt

—> Abfahrtsplan mit nach Zeiten geordneten Abfahrtszeiten (mit Befehl ORDER BY)

—> Ankunftsgleis und Abfahrtsbahnhof sind in diesem Fall unwichtig

EM-Übung U21 2017

Relationenschema und Kardinalitäten erzeugen

Erstellen der Tabellen

Entity 1: Land

Gruppe	Name	LandNr (LNr)
A	England	1
A	Slowakei	2
A	Schweden	3
A	Polen	4
B	Spanien	5
B	Portugal	6
B	Serbien	7
B	EJR Mazedonien	8
C	Italien	9
C	Deutschland	10
C	Dänemark	11
C	Tschechische Republik	12

Entity 2: Stadion

StadionNr (SNr)	Ort	Name
10	Kielce	Kielce Stadium
20	Lublin	Lublin Stadium
30	Bydgoszcz	Bydgoszcz Stadium
40	Gdynia	Gdynia Stadium
50	Tychy	Tychy Stadium
60	Krakow	Krakow Stadium

Entity 3: Speiltermin

SpielterminNr (StNr)	Datum	SNr	Gruppenphase
1	16.Juni.17	10	Gruppenphase 1
2	16.Juni.17	20	Gruppenphase 1
3	17.Juni.17	30	Gruppenphase 1
4	17.Juni.17	40	Gruppenphase 1
5	18.Juni.17	50	Gruppenphase 1
6	18.Juni.17	60	Gruppenphase 1
7	19.Juni.17	10	Gruppenphase 2
8	19.Juni.17	20	Gruppenphase 2
9	20.Juni.17	30	Gruppenphase 2
10	20.Juni.17	40	Gruppenphase 2
11	21.Juni.17	50	Gruppenphase 2
12	21.Juni.17	60	Gruppenphase 2
13	22.Juni.17	20	Gruppenphase 3
14	22.Juni.17	10	Gruppenphase 3
15	23.Juni.17	30	Gruppenphase 3
16	23.Juni.17	40	Gruppenphase 3
17	24.Juni.17	50	Gruppenphase 3
18	24.Juni.17	60	Gruppenphase 3
19	27.Juni.17	50	Halbfinale
20	27.Juni.17	60	Halbfinale
21	30.Juni.17	60	Finale

Entity 4: Ergebnis

ErgebnisNr (ENr)	StNr	LNr	Tore
30	1	3	0
35	1	1	0
40	2	4	1
45	2	2	2
50	3	6	2
55	3	7	0
60	4	5	5
65	4	8	0
70	5	10	2
75	5	12	0
80	6	11	0
85	6	9	2
90	7	2	1
95	7	1	2
100	8	4	2
105	8	3	2
110	9	7	2
115	9	8	2
120	10	6	1
125	10	5	3
130	11	12	3
135	11	9	1
140	12	10	3
145	12	11	0
150	13	2	3
155	13	3	0
160	14	1	3
165	14	4	0
170	15	7	0
175	15	5	1
180	16	8	2
185	16	6	4
190	17	12	2
195	17	11	4
200	18	9	1
205	18	10	0
210	19	1	2
215	19	10	2
220	20	5	3
225	20	9	1
230	21	10	1
235	21	5	0

Modellieren eines ER Modells und Umsetzung in eine Datenbank am Beispiel der UEFA Fußball U21 EM 2017:

Vorgehen:

• Welche Mannschaften haben am 18. Juni gespielt?
• Wie viele Mannschaften haben 3 Tore erzielt?
• Welche Mannschaften waren im Halbfinale und aus welchen Gruppen kamen diese?
• In welchen Stadien erfolgte die Gruppenphase 1?
• Welche Mannschaften haben im Krakow Stadium gespielt?

Fazit

Bei dem Seminar „Informationssysteme“ hatte ich, ähnlich wie beim Seminar „HTML“, zu Anfangs ein paar Probleme mich in die Inhalte einzufinden und die Zusammenhänge zu verstehen. Nach den ersten Übungen habe Ich aber immer mehr gefallen an der Erstellung von Datenbanken gefunden und habe die Aufgaben gerne bearbeitet, auch wenn sie manchmal ein wenig Zeit gebraucht haben. Alles in allem habe ich sehr viel dazu gelernt und kann heute sagen „Ich kann eine Datenbank erstellen“, womit ich am Anfang niemals gerechnet hätte.