02 - BIR - Grundlagen Relationaler Datenbanken

Business Intelligence und Reporting
2. Grundlagen relationaler
Datenbanken
Prof. Dr. Christian Janiesch
Juniorprofessor für Information Management

Josef-Stangl-Platz 2 Part 1
97070 Würzburg
http://www.bwl.uni-wuerzburg.de/lehrstuehle/bwljp1/
Übersicht der Vorlesung
Grundlagen Data 1. Einführung

2. Grundlagen
3. Architektur
relationaler DBs
Warehouse
Architektur und 4. Modellierung

5. ETL, OLAP 6. Reporting &
& MDX Visualisierung
Anwendung
8. Einführung,
Projektierung im 7. Informations-
Betrieb und
bedarfsanalyse
BI-Umfeld Wartung
Spezialformen 9. Operational BI
10. Zukunft von
DW & BI
und Ausblick
1 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

Datenbanken
▪ Eine Datenbank ist eine logisch zusammenhängende

Sammlung von Daten mit einer bestimmten inhärenten
Bedeutung. Eine zufällige Datensammlung wird nicht als
Datenbank bezeichnet.
▪ Ein Datenbankmanagementsystem (DBMS) ist ein

Softwaresystem (…), das dem Benutzer das Erstellen und
die Pflege einer Datenbank ermöglicht.
Elmasri, Navathe (2009)

Architektur Integrierter Informationssysteme
Organisationssicht
Datensicht Prozesssicht Funktionssicht
Scheer (1992)

Entity-Relationship-Model (ERM)
Teil 1

Entity-Relationship Model
▪ Peter Pin-Shan Chen:

The Entity-Relationship Model:
Toward a Unified View of Data.
ACM Transactions on Database
Systems 1 (1) 1976, S. 9-36.
Chen (1976)

Entitäten und Beziehungen
Chen (2002)

Abstraktionskonzepte
▪ Klassifikation
□ Definition von Klassen von Objekten mit gemeinsamen Eigenschaften
□ Beispiel: Personen, Autos, Flugzeuge, …
▪ Aggregation
□ Definition von Klassen von Objekten aus existierenden Komponenten
□ Beispiel: Name, Geschlecht -> Person
▪ Verallgemeinerung und Spezialisierung

□ Definition von Teilmengenbeziehungen zwischen Elementen
verschiedener Klassen (inkl. Vererbung)
□ Beispiel: Mann, Frau -> Person -> Student, Professor
Vossen (2008)

Entitäten, Beziehungen, Attribute
▪ Entitätstyp (entity type)

□ Gesamtheit aller gleichartigen Objekte
□ bspw. Personen, Vorlesungen
▪ Beziehungstyp (relationship type)

□ Gesamtheit aller Beziehungen von Objekten
□ bspw. “hört” oder “liest”
▪ Attribut (attribute)
□ Eigenschaft von einem Entitätstyp oder einem
Beziehungstyp
□ bspw. Name, Datum, ID

Schlüsselkandidaten und Schlüsselattribut
▪ Schlüsselkandidaten sind diejenigen Attribute, die einen

Entitätstyp eindeutig identifizieren können
▪ Ein Schlüsselattribut ist der Schlüsselkandidat, der zur

eindeutigen Identifizierung verwendet wird
▪ Das Schlüsselattribut wird immer unterstrichen dargestellt
Matrikel-
nummer

Nullwerte
▪ Es gibt Fälle, in denen ein Attribut für eine Entität keinen

Wert enthält
Titel
▪ Es gibt Fälle, in denen der Wert für ein Attribut einer Entität
nicht bekannt ist
▪ 0 ist kein Nullwert!

▪ Notwendigkeit von Nullwerten sollte immer kritisch hinterfragt
werden
Elmasri, Navathe (2009)

Beziehungen
Veran-
Matrikel- staltungs- Bezeichnung
Name
nummer nummer
VL-
Student Besuch Vorlesung

Kardinalitäten
▪ Kardinalitäten legen fest, wie viele Entitäten eines

Entitätstypen mit einer Entität des verbundenen Entitätstypen
(und umgekehrt) in Beziehung stehen können oder
müssen
▪ Wie oft muss eine Entität mindestens eine Beziehung

eingehen?
▪ Wie oft kann sie maximal eine Beziehung eingehen?
▪ 2 (min, max)-Paare notwendig

▪ Bei einer Minimum-Kardinalität mit dem Wert 1, spricht man
von einer existenziellen Abhängigkeit

(0,1) : (0,1)
E1 E2

(0,n) : (1,1)
E
E11 EE22

Kardinalitäten
Veran-
Matrikel- staltungs- Bezeichnung
Name
nummer nummer
(0,n) VL- (0,n)

Student Besuch Vorlesung

Notationsvergleich
(1,1) (0,n)
▪ Min-Max / ISO Student
Stu-
dium Hauptfach
N 1
▪ Chen Student
Stu-
dium Hauptfach
▪ Krähenfuß Student Hauptfach
<<Relationship>>
hat >
0..N
▪ UML
< Hauptfach von
Student Hauptfach
1

Zeit in Datenmodellen
▪ Die Fixierung von Informationen auf Zeitpunkte, die

Erfassung der historischen Dimension des
Weltausschnitts ist für viele Datenmodelle von großer
Bedeutung.
ISBN,Titel,
Seitenzahl
▪ Zeitpunkte Buch
□ Als Datum Erscheinungs-
datum
▪ Zeitabschnitte
entliehen am,
□ Anfang und Ende je als ein Attribut zurück am
Entleihnummer

Parallele Kanten als Hierarchie
Person
(0,n)
(0,1) Hierar-
chie

Parallele Kanten als Netzwerkstruktur
Person
(0,n)
(0,n) Netz-
werk

Ternär
(1,n) Vor-
Professor
lesung
(1,n)
(1,1)
(1,n)
Prüfung Modul
(1,n)
(1,n)
(1,n) Teil-
Student
nahme

N-när
E1
(0,n)
(0,n) (0,n)
En E-E-E-E E2
(0,n)
E3

Relational Model nach Codd
Teil 2

Relational Model
▪ Edgar Frank „Ted“ Codd:

A Relational Model of Data for
Large Shared Data Banks.
Communications of the ACM
6 (13) 1970, S. 377-387.
Codd (1970)

Relationales Modell
Attribut (Spalte)
Relationenname
R
A1 ... An Relationenschema
... ... ...

Tupel (Zeile)
... ... ...
... ... ...
... ... ...
Wert Relation (Tabelle)

Primärschlüsselattribut (Wiederholung)
▪ Schlüssel
□ minimale Menge von Attributen, deren Werte ein Tupel immer
eindeutig identifizieren
□ hat für jedes Tupel eine andere Ausprägung (UNIQUE)
□ muss entsprechend existieren (NOT NULL)
□ besondere Bedeutung bei der Referenzierung von Tupeln
□ einer der Schlüsselkandidaten wird als Primärschlüssel ausgewählt
▪ Unterscheidung
□ Merkmalsschlüssel (z.B. Name)
□ künstlicher Schlüssel (z.B. Bestellnummer)
□ Kombination aus Schlüsseln (z.B. Gebäude- und Raumnummer)
▪ Primärschlüssel
□ wird unterstrichen
□ Angestellte AKW Springfield (Vorname, Nachname, ID)
Kemper, Eickler (2013)

Weitere Schlüsselattribute
▪ Sekundärschlüssel
□ auch Schlüsselkandidaten (candidate key) genannt
□ sonst Eigenschaften wie Schlüssel
▪ Fremdschlüssel
□ auch: relationale Verknüpfung
□ wird mit # gekennzeichnet
□ Attribut
□ (welches nicht alleiniger Primärschlüssel ist)
□ welches den selben Wertebereich hat wie ein Primärschlüssel in einer
anderen Relation
□ welches beide Relationen miteinander verbindet
Staud (1995)

Relationale Verknüpfung
Relation Stadt
StadtID Name #BundeslandID
1 Würzburg BAY
2 Nürnberg BAY
3 Bremen BRE
... ... ...
Relation Staat
StaatID Name
Relation Bundesland 1 Deutschland
BundeslandID Name #StaatID 2 Malta
BAY Bayern 1 3 Liechtenstein
BRA Brandenburg 1 ... ...
BRE Bremen 1
... ... ...

Datenintegrität
▪ Objektintegrität
□ kein Tupel mit unvollständigem Schlüssel in einer Relation
▪ Referentielle Integrität
□ ein Fremdschlüssel (Ausprägung) darf nur eingetragen werden,
wenn er als Ausprägung des Schlüssels in einer anderen Relation
existiert
□ sonst können Fremdschlüsseleinträge nicht verknüpft werden
▪ Semantische Integrität
□ Logische Widerspruchsfreiheit und exakte Abbildung des
modellierten Realweltausschnitts

Transformation Entitätstyp
▪ Entitätstypen werden immer zu eigenen Relationen

□ Tabellen mit mindestens einer Spalte
□ Spalte des Primärschlüssels
Relation Kunde
KundenID
Kunde
...
...
KundenID

Transformation Attribut
▪ Attribute werden immer zu Spalten in Relationen

□ Weiteren Spalten neben dem Primärschlüssel
Relation Kunde
KundenID Name
Kunde
... ...
... ...
KundenID Name

Transformation Beziehungstyp
▪ Beziehungstypen werden manchmal zu eigenen Relationen

□ Sie erben die Primärschlüsselattribute der eingehenden
Entitätstypen
□ Ist dies der Fall, dann erhalten die entsprechenden Relationen
immer die Schlüssel der Entitätstypen als sogenannte
Fremdschlüssel

Transformation Relationenschema zu ERM
▪ Transformationsregeln vom Relationenschema ins ERM

können grundsätzlich nicht strikt angegeben werden,
wenn nicht sämtliche Constraints angegeben sind
▪ Constraints, die die Überführung unterstützen würden, liegen

nicht notwendigerweise vor
▪ Das Relationenschema allein reicht zur Überführung nicht

aus, vielmehr müssen die Tabelleneinträge interpretiert
werden

Structured Query Languague (SQL)
Teil 3

Grundlagen
▪ SQL = Structured Query Language
▪ SQL basiert auf der von Codd entwickelten Relationalen Algebra
▪ Deklarative Programmiersprache
□ Algorithmische Lösung eines Problems nicht im Vordergrund
□ Beschreibung des Problems
▪ Beispiel
□ SELECT * FROM Kunde;
▪ De facto Standardsprache für relationales Datenbankmodell

Befehlsklassen
▪ SQL als Data Definition Language (DDL)

□ Anlegen, Ändern, Löschen von Tabellen
▪ SQL als Data Manipulation Language (DML)

□ Einfügen, Ändern, Löschen von Daten
▪ SQL als Data Query Language (DQL)

□ Ausführen von Abfragen auf Datenbestand
▪ SQL als Data Control Language (DCL)

□ Benutzer- und Transaktionsverwaltung

Anlegen einer Tabelle
▪ Syntax:
CREATE TABLE tabellenname(
Spaltendefinition1,
Spaltendefinition2, …,
Spaltendefinitionn
[PRIMARY KEY (spaltenname,…)]
[UNIQUE (spaltenname,…)]
[FOREIGN KEY (spaltenname,…) REFERENCES
tabellenname(spaltenname,…)
[ON DELETE referenzoption]
[ON UPDATE referenzoption]
]
);

Spaltendefinition
▪ Syntax
spaltenname datentyp [UNSIGNED][NULL | NOT NULL]
[DEFAULT default-wert] [AUTO-INCREMENT][UNIQUE |
PRIMARY KEY]
▪ Beispiele
□ Produktnummer INTEGER UNSIGNED NOT NULL UNIQUE
□ Verkaufspreis DECIMAL(5,2) NOT NULL
□ KNr INTEGER UNSIGNED AUTO_INCREMENT PRIMARY KEY

Anlegen einer Tabelle
▪ Syntax:
CREATE TABLE tabellenname(
Spaltendefinition1,
Spaltendefinition2, …,
Spaltendefinitionn
[PRIMARY KEY (spaltenname,…)]
[UNIQUE (spaltenname,…)]
[FOREIGN KEY (spaltenname,…) REFERENCES
tabellenname(spaltenname,…)
[ON DELETE referenzoption]
[ON UPDATE referenzoption]
]
);

Referentielle Integrität
▪ Stellt sicher, dass Werte in Fremdschlüsselspalten auf

tatsächlich existierende Werte in der referenzierten Spalte
verweisen
▪ Sicherstellung der Integrität ist Aufgabe des DBMS
▪ Referenzoptionen: NO ACTION, CASCADE, SET NULL
▪ Beispiel:
PNr Name #PGNr PGNr Name
1 Produkt A 1 1 Produktgruppe 1
2 Produkt B 1 2 Produktgruppe 2
3 Produkt C 1
4 Produkt D 2
5 Produkt E 2

Direktes Einfügen von Daten
▪ Syntax
INSERT INTO tabellenname [(spaltenname1, …)]
VALUES ({ausdruck | DEFAULT}, …);
▪ Beispiel
INSERT INTO Veranstaltung
VALUES (DEFAULT, 'Business Intelligence und
Reporting', 'BIR', 'V', 5, 'Saugut, muss man
hören!!!');

Ändern von Daten
▪ Syntax
UPDATE tabellenname
SET spaltenname1 = ausdruck1 [, spaltenname2 =
ausdruck2, …]
[WHERE bedingung];
▪ Beispiel
□ Die SWS-Anzahl der Veranstaltung „BIR“ soll von 5 auf 6 erhöht
werden
UPDATE Veranstaltung
SET SWS = 6
WHERE Kuerzel = 'BIR';

Aufbau einer Abfrage
▪ Syntax
SELECT [ALL | DISTINCT] spaltenname1, ….
FROM tabelle1 [, tabelle2, …]
[WHERE bedingung];
▪ Beispiel
□ Zeige alle Kunden an.
SELECT * FROM Kunde;
□ Zeige alle Artikel mit Lagerbestand von weniger als 50 an.
SELECT Artikelname, Lagerbestand
FROM Artikel
WHERE Lagerbestand < 50;

 Selektion
▪ Bei der Selektion wird mit einem Vergleichsausdruck

festgelegt, welche Tupel in die Ergebnisrelation
aufgenommen werden sollen
▪ D.h. es werden Tupel („Zeilen“) ausgeblendet
R
A B C A=a3(R)
a1 b1 c1 A=a (R) A B C
3
a1 b2 c2 a3 b2 c2
a3 b2 c2

 Selektion in SQL
▪ SELECT * R
FROM tabellenname A B C
WHERE ausdruck; 1 3 3
2 2 1
▪ SELECT * R 3 1 2
FROM R A B C
WHERE A=1; 1 3 3
▪ Selektiere alle A mit mindestens 2 aus R. R

▪ SELECT * A B C
FROM R 2 2 1
WHERE A >= 2; oder A > 1;
3 1 2

Π Projektion
▪ Bei der Projektion wird mit einem Vergleichsausdruck

festgelegt, welche Attribute in die Ergebnisrelation
aufgenommen werden sollen
▪ D.h. es werden Attribute („Spalten“) ausgeblendet
▪ Duplikate werden eliminiert
R B,C(R)
A B C B C
a1 b1 c1 ΠB,C(R) b1 c1
a2 b2 c2 b2 c2
a3 b2 c2

Π Projektion in SQL
▪ SELECT spaltenname R
FROM tabellenname; A B C
1 3 3
▪ SELECT A, C R 2 2 1
FROM R; A C 3 1 2
1 3
2 1
3 2
▪ Selektiere nur A kleiner 2 und liefere deren B zurück. R

▪ SELECT B B
FROM R
WHERE A < 2; 3

 Umbenennung
▪ Bei der Umbenennung werden Attribute oder Relationen neu

bezeichnet
▪ D.h. Attribute („Spalten“) und Relationen („Tabellen“)
bekommen gleiche oder unterschiedliche Bezeichner
□ für Joins unterschiedlich benannter Relationen
□ für kartesische Produkte bei gleichen Attributen
□ für Mengenoperationen
R X←B(R)
A B C A X C
a1 b1 c1 X←B(R) a1 b1 c1
a1 b2 c2 a1 b2 c2
a3 b2 c2 a3 b2 c2

 Umbenennung in SQL
▪ SELECT spaltenname AS spaltenname R

FROM tabellenname; A B C
1 3 3
▪ SELECT A, B AS X, C R 2 2 1
FROM R; A X C 3 1 2
1 3 3
2 2 1
3 1 2
▪ Selektiere nur A kleiner 2 und liefere deren C als P zurück.

▪ SELECT C AS P R
FROM R P
WHERE A < 2; 3
γ Aggregation
▪ Die Aggregation erlaubt die Gruppierung gleicher Tupel,

auf die eine Aggregatfunktion angewendet wird, so dass für
die gesamte Gruppe ein Wert bestimmt wird
▪ Typische Aggregatfunktionen sind:
□ count, sum, min, max, avg, std
R A;count(*)(R)
A B C A count(*)
a1 b1 c1 γA;count(*)(R) a1 2
a2 b2 c2 a2 1
a1 b2 c2

γ Aggregation in SQL: Beispiele
▪ COUNT()
□ Ermittelt Anzahl an Zeilen, die eine bestimmte Suchbedingung
erfüllen
▪ MIN() / MAX()
□ Gibt den minimalen bzw. maximalen Wert einer Spalte zurück
□ Spalte muss nicht numerischen Datentyp haben
▪ SUM()
□ Ermittelt Summe aller Werte einer Spalte
□ Nur numerische Datentypen erlaubt
□ Ergebnis muss im Bereich der darstellbaren Zahlen des Input-
Datentyps liegen
▪ AVG()
□ Ermittelt Durchschnitt aller Werte einer Spalte
□ Nur numerische Datentypen erlaubt
□ Auf NULL-Werte achten

⋈ Equi-Join (Inner Join)
▪ Beim Equi-Join (Gleichverbund) wird als erstes das

kartesische Produkt zweier Relationen gebildet
▪ Dann erfolgt die Selektion mit der Bedingung, dass der
Inhalt bestimmter Spalten identisch sein muss
▪ D.h. die neue Relation verbindet beide Relationen anhand
eines Merkmals
R L R⋈C=DL
A B C R⋈C=DL D E A B C D E
a1 b1 c1 c1 e1 a1 b1 c1 c1 e1
a1 b2 c2 c2 e2 a1 b2 c2 c2 e2
a3 b2 c2 a3 b2 c2 c2 e2

⋈ Equi-Join in SQL
▪ SELECT * R L
FROM tabellenname1 A B C D E
INNER JOIN tabellenname2 1 9 1 1 3
ON ausdruck;
2 8 2 2 3
3 7 2
▪ SELECT *
FROM R R⋈C=DL
INNER JOIN L A B C D E
ON R.C = L.D; 1 9 1 1 3
2 8 2 2 3
▪ Alternativ 3 7 2 2 3
SELECT *
FROM R, L
WHERE R.C = L.D
⋈ Natural Join
▪ Beim Natural Join (natürlicher Verbund) wird als erstes das

kartesische Produkt zweier Relationen gebildet
▪ Dann erfolgt die Selektion mit der Bedingung, dass der
Inhalt bestimmter Spalten identisch sein muss
▪ Gleiche Spalten werden ausgeblendet
▪ Eigenschaften
□ kommutativ (L ⋈ R = R ⋈ L)
□ assoziativ (L ⋈ R) ⋈ T = L ⋈ (R ⋈ T)
R L R⋈L
A B C R⋈L C D A B C D
a1 b1 c1 c1 d1 a1 b1 c1 d1
a1 b2 c2 c2 d2 a1 b2 c2 d2
a3 b2 c2 a3 b2 c2 d2
⋈ Natural Join in SQL
▪ SELECT * R L
FROM tabellenname1 A B C C D
NATURAL JOIN tabellenname2; 1 9 1 1 2
2 8 2 2 3
▪ SELECT * 3 7 2
FROM R
NATURAL JOIN L; R⋈L
A B C D
▪ Alternativ 1 9 1 2
SELECT * 2 8 2 3
FROM R 3 7 2 3
INNER JOIN L
USING(C);

Left (Outer) Join
▪ Beim Left (Outer) Join werden auch diejenigen Tupel der

linken Tabelle mit in die Ereignisrelation aufgenommen, die
keinen Join-Partner gefunden haben
R L R⋈L
A B C C D A B C D
a1 b1 c1 c1 d1 a1 b1 c1 d1
a1 b2 c2 c4 d2 a1 b2 c2 NULL
a3 b2 c3 a3 b2 c3 NULL
▪ SELECT * FROM R NATURAL LEFT OUTER JOIN L;
▪ Ohne Natural Join (und mit 2 C-Spalten)

▪ SELECT * FROM R LEFT OUTER JOIN L ON R.C=L.C;

Right (Outer) Join
▪ Beim Right (Outer) Join werden auch diejenigen Tupel der

rechten Tabelle mit in die Ereignisrelation aufgenommen, die
keinen Join-Partner gefunden haben
R L R⋈L
A B C C D A B C D
a1 b1 c1 c1 d1 a1 b1 c1 d1
a1 b2 c2 c4 d2 NULL NULL c4 d2
a3 b2 c3
▪ SELECT * FROM R NATURAL RIGHT OUTER JOIN L;

▪ SELECT * FROM R RIGHT OUTER JOIN L ON R.C=L.C;

Full (Outer) Join
▪ Beim Full (Outer) Join werden auch alle Tupel mit in die
Ereignisrelation aufgenommen, die keinen Join-Partner
gefunden haben
R⋈L
R L A B C D
A B C C D a1 b1 c1 d1
a3 b2 c3 NULL NULL c4 d2
▪ SELECT * FROM R FULL OUTER JOIN L USING(C);

▪ SELECT * FROM R FULL OUTER JOIN L ON R.C=L.C;

Aufbau einer komplexen Abfrage
▪ Syntax
SELECT spaltendefinition1, spaltendefinition2, …,
aggregatfunktion(spaltendefinitionx)
FROM tabellenname1, tabellename2, …
WHERE suchbedingung
GROUP BY spaltendefinition1, spaltendefinition2,
…
[HAVING gruppenbedingung]
[ORDER BY spaltendefinitioni [ASC|DESC]];

Gruppierung: GROUP BY
▪ Gruppierung von Zeilen anhand der Zeilenwerte

□ Spalten, nach denen gruppiert wird, enthalten keine doppelten
Zeileneinträge mehr
▪ Nach GROUP BY erfolgt Spezifikation aller Spalten, über die
gruppiert wird
▪ Wenn über mehrere Spalten gruppiert wird, dann

Untergruppen bilden
▪ Bei Gruppierung
□ im SELECT-Statement nur Spalten, über die gruppiert wird,
□ oder Ausdrücke, die genau einen Wert pro Gruppe zurückgeben
(Aggregatfunktionen)

Gruppenbedingungen: HAVING
▪ Optionale Auswahl bestimmter Gruppen

▪ Wird entsprechend auf die GROUP BY–Klausel angewendet
▪ Nur Gruppen angezeigt, die HAVING-Bedingung erfüllen
▪ Unterschied zu WHERE-Bedingung
□ HAVING wird nicht auf Zeilen, sondern auf Gruppen von Zeilen
angewendet
□ Zeilen, die WHERE-Bedingung nicht erfüllen, werden gar nicht erst in
Ergebnismenge aufgenommen
□ Zeilen, die HAVING-Bedingung nicht erfüllen, werden in
Ergebnismenge aufgenommen, aber ausgeblendet
▪ Aggregatfunktionen in HAVING-Bedingungen

Sortieren der Ergebnismenge: ORDER BY
▪ Die Ergebnismenge kann optional nach einer oder mehreren

Spalten mit ORDER BY sortiert werden
▪ Für jede Spalte kann Sortierung aufsteigend ASC oder

absteigend DESC erfolgen
▪ Wenn keine Angabe der Sortierungsreihenfolge, dann

Default ASC
▪ Beispiel
SELECT PLZ, Firma
FROM Kunde
ORDER BY PLZ DESC, Firma;
Unterabfrage (Subquery)
▪ Strukturierter Aufbau komplexer Abfragen

▪ Weitere SELECT…FROM…WHERE-Abfragen innerhalb eines
SELECT-Befehls
▪ Innere Abfrage = Unterabfrage (Subquery)

▪ Äußere Abfrage = Hauptabfrage
▪ Weitere Verschachtelungen möglich
▪ Vier Arten von Unterabfragen

□ Skalar-, Spalten-, Zeilen- und Tabellenunterabfrage
□ Unterscheidung nach Ergebnistyp

Views
▪ Sicht auf Datenbank
▪ Logische Relation, die im DBMS über eine gespeicherte

Abfrage vorgehalten werden
▪ View als Alias für eine Abfrage
▪ Einbinden externer Schemata

Business Intelligence und Reporting
Haben Sie Fragen?
Prof. Dr. Christian Janiesch
Juniorprofessor für Information Management

Josef-Stangl-Platz 2 Part 1
97070 Würzburg
http://www.bwl.uni-wuerzburg.de/lehrstuehle/bwljp1/

02 - BIR - Grundlagen Relationaler Datenbanken

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

02 - BIR - Grundlagen Relationaler Datenbanken

Hochgeladen von

Copyright:

Verfügbare Formate

Business Intelligence und Reporting

Prof. Dr. Christian Janiesch

Juniorprofessor für Information Management

Grundlagen Data 1. Einführung

Architektur und 4. Modellierung

1 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Eine Datenbank ist eine logisch zusammenhängende

▪ Ein Datenbankmanagementsystem (DBMS) ist ein

Elmasri, Navathe (2009)

2 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

Datensicht Prozesssicht Funktionssicht

3 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

4 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Peter Pin-Shan Chen:

5 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

6 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Verallgemeinerung und Spezialisierung

7 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Entitätstyp (entity type)

▪ Beziehungstyp (relationship type)

8 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Schlüsselkandidaten sind diejenigen Attribute, die einen

▪ Ein Schlüsselattribut ist der Schlüsselkandidat, der zur

▪ Das Schlüsselattribut wird immer unterstrichen dargestellt

9 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Es gibt Fälle, in denen ein Attribut für eine Entität keinen

▪ 0 ist kein Nullwert!

10 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

11 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Kardinalitäten legen fest, wie viele Entitäten eines

▪ Wie oft muss eine Entität mindestens eine Beziehung

▪ 2 (min, max)-Paare notwendig

12 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

13 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

14 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

(0,n) VL- (0,n)

15 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Krähenfuß Student Hauptfach

16 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Die Fixierung von Informationen auf Zeitpunkte, die

17 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

18 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

19 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

20 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

21 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

22 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Edgar Frank „Ted“ Codd:

23 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

... ... ...

Wert Relation (Tabelle)

24 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

25 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

26 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

Relation Bundesland 1 Deutschland

BundeslandID Name #StaatID 2 Malta

BAY Bayern 1 3 Liechtenstein

BRA Brandenburg 1 ... ...

27 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

28 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Entitätstypen werden immer zu eigenen Relationen

29 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch

▪ Attribute werden immer zu Spalten in Relationen

30 Business Intelligence und Reporting – Prof. Dr. Christian Janiesch