Vorlesung Informaitonsintegration

Informationsintegration
Multidatenbanksprachen
Schema SQL: Konzept und Implementierung
Ulf Leser
Wissensmanagement in der
Bioinformatik
Wo sind wir?
• Architekturen und Kriterien
•
•
•
Szenarien, Abgrenzung und Einsatzgebiete
Verteilung, Autonomie, Heterogenität, Transparenz
Architekturen
• Data Warehouses
• Mediator-basierte Systeme
• Multidatenbanksprachen, SchemaSQL
• Techniken zur Anfrageplanung in föderierten Systemen
•
•
•
Local-as-View und Global-as-View Korrespondenzen
Anfrageplanung mit LaV
Query Containment und Answering Queries using Views
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
3
Inhalt 2
• Verteilte Anfrageoptimierung
•
•
•
Kostenbasierte verteilte Optimierung
Semi-Joins
Umgang mit beschränkten Quellen
• Schemamanagement
•
•
•
Schemaintegration
Schema Matching
Schema Mapping
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
4
Inhalt 3
• Datenintegration
•
•
•
Informationsqualität
Duplikaterkennung
Datenfusion
• Semantische Integration
•
•
Ontologien und Beschreibungslogiken
Semantic Web
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
5
Buch
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
6
Buch
Jetzt
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
7
Buch
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
8
Buch
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
9
Handels - DWH
Verkaufen wir
im Wedding
mehr Dosenbier
als in
Zehlendorf?
FILIALE 3
...
FILIALE 1
FILIALE 2
DWH
Artikeldaten
Analyse
Kundendaten
Welches sind
meine
Topkunden ?
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Lieferantendaten
10
OLAP versus OLTP
OLTP
OLAP
Insert, Update, Delete, Select
Select
Bulk-Inserts
Viele und kurz
Lesetransaktionen
Einfache Queries,
Primärschlüsselzugriff,
Schnelle Abfolgen von
Selects/inserts/updates/deletes
Komplexe Queries: Aggregate,
Gruppierung, Subselects, etc.
Bereichsanfragen über mehrere
Attribute
Wenige Tupel
Mega-/ Gigabyte
Gigabyte
Terabyte
Eigenschaften der Daten
Rohdaten, häufige Änderungen
Abgeleitete Daten,
historisch & stabil
Erwartete Antwortzeiten
Echtzeit bis wenige Sek.
Minuten
Anwendungsorientiert
Themenorientiert
Sachbearbeiter
Management
Typische Operationen
Transaktionen
Typische Anfragen
Daten pro Operation
Datenmenge in DB
Modellierung
Typische Benutzer
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
11
DWH Architektur & Komponenten
Monitoring
Metadaten
Quelle 1
RDBMS
Quelle 2
IMS
Staging Area
Staging Area
Datenquellen
Analysewerkzeuge
Mart 2
Cube
Basisdaten
Mart 1
Abgeleitete Sichten
Arbeitsbereich
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
12
Multidimensionales Schema
customer
id
name
cust_class
time
id
day
month
year
•
•
•
•
•
product
id
name
product_group
line_item
order_id
product_id
amount
single_price
discount_rate
supply
id
region
Technische Informationen raus (Session)
Nur abgeschlossene Bestellungen aufnehmen (Orderstatus)
Zusammenfassen (discount_rate)
Denormalisieren (überall)
Konzentration auf Businessobjekte und -prozesse
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
13
Cube
Bier Verkäufe in
BWB in 2002
Time
2002
Product
Sales
Cube
2001
2000
Limo
1999
Bier
BWB
Bayern
Berlin
NRW
Location
Cube -> Hypercube: Bon / Lieferant / Kunde / ...
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
14
Dimension
Dimensions
schema
Jahr
Quartal
Monat
Tag
1997
I
1998
1999
II III IV
Klassifikationsstufen
Jan Feb Mar
1 ... 31
Top
2000
I
II III IV
Okt Nov Dez
1 ... 28
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Klassifikationsknoten
15
Beispiel: Aggregation (Roll-Up)
Z.Monat
Z.Tag
4.1.1999
B.Abteilung
4‘1999
B.Abt.
3‘1999
3.1.1999
2.1.1999
Skoda.Reparatur
Skoda.Ersatzteile
1.1.1999
2‘1999
Skoda.Repa.
Skoda.Ersatz
1‘1999
Lyon
Nantes
Wedding
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
München
Lyon
Nantes
Wedding
München
R.Shop
R.Shop
16
Variante 2: Star Schema
Product
product_id
product_name
pg_id
pg_name
Time
day_id
day
month_id
month
year_id
year
Sales
product_id
day_id
shop_id
amount
price
Localization
shop_id
shop_name
region_id
region_name
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
17
ROLLUP Beispiel
SELECT
FROM
WHERE
GROUP BY
T.year_id, T.month_id, T.day_id, sum(...)
sales S, time T
T.day_id = S.day_id
ROLLUP(T.year_id, T.month_id, T.day_id)
1997
Jan
1
1997
Jan
...
1997
Jan
31
1997
Jan
ALL
1997
Feb
...
1997
March
ALL
1997
...
...
1997
ALL
ALL
1998
Jan
1
1998
...
...
1998
ALL
ALL
...
...
...
ALL
ALL
ALL
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
200
300
31.000
450
1.456.400
100
45.000
12.445.750
18
Multidimensionale Aggregation
Verkäufe nach Produktgruppen und Jahren
1998
1999
2000
Gesamt
Weine
15
17
13
45
Biere
10
15
11
36
Gesamt
25
32
24
81
•
•
•
•
sum() ... GROUP BY
sum() ... GROUP BY
Wie...
vieleGROUP
Queries
sum()
BY
sum()
pg_id, year_id
pg_id
sind
notwendig ?
year_id
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
19
ETL - Übersicht
• Aufgabe
•
•
•
Regelmäßige Extraktion von Änderungsdaten aus Quellen
Datenversorgung des DWH
Sicherung der DWH Konsistenz bzgl. Datenquellen
• Zwei Schritte
•
Von den Quellen zur Staging Area
• Extraction von Daten aus den Quellen
• Erstellen / Erkennen von differentiellen Updates
• Erstellen von LOAD Files
•
Von der Staging Area zur Basisdatenbank
• Data Cleaning und Tagging
• Erstellung integrierter Datenbestände
¾ Effiziente Methoden essentiell -> Sperrzeiten minimieren
¾ Rigorose Prüfungen essentiell -> Datenqualität sichern
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
20
Art der Daten
• Snapshots: Quelle liefert immer kompletten Datenbestand
•
¾
¾
¾
Neuer Lieferantenkatalog, neue Preisliste, etc.
Änderungen erkennen
Differential Snapshot Problem [LGM96]
Historie korrekt abbilden
• Logs: Quelle liefert jede Änderung
• Transaktionslogs, anwendungsgesteuertes Logging
¾ Änderungen effizient einspielen
• Nettologs: Quelle liefert Netto-Änderungen
• Nettoänderungen seid dem letzten Snapshot (Snapshot-Deltas)
¾ Keine vollständige Historie möglich
¾ Änderungen direkt einspielbar
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
21
Transformation
• Aufgabe
•
Umwandlung der Daten in eine „DWH-gerechte“ Form
• Form follows Function
•
•
Quellen: hoher Transaktionsdurchsatz
DWH: spezifische statistische Analysen
• Arten von Transformationen
•
•
Schematransformation
Datentransformation
• Transformationen möglich an zwei Stellen
•
•
Transformation der Quell-Extrakte zu Load-Files
Transformation von der Staging-Area in die Basis-DB
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
22
Zusammenfassung
Quelle -> Arbeitsbereich
Arbeitsbereich ->
Basis-DB
Art des Zugriffs
Satzorientiert
Mengenorientiert
Verfügbare
Datenbasen
Eine Quelle (Updatefile)
Viele Quellen
Verfügbare
Datensätze
Quellabhängig: Alle, alle
Änderungen, Deltas
Zusätzlich Basis-DB
verfügbar
Programmiersprachen
Skripte: Perl, AWK, ... oder 3GL SQL, PL/SQL
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
23
BULK Load
• DB-spezifische Erweiterungen zum Laden großer
Datenmengen
• Beispiel Oracle: sqlldr (DIRECTPATH option)
• Läuft (meist) mit Einschränkunen
•
•
•
•
•
Tabellensperre
Keine Beachtung von Triggern oder Constraints
Indexe werden erst nach Abschluss aktualisiert
Kein transaktionaler Kontext (kein Logging)
Kein Abbruch bei Fehlern
• Datei mit „bad records“
• Checkpoints zum Wiederaufsetzen
• … (siehe Dokumentation)
¾ Praxis: BULK Uploads
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
24
Data Warehouse vs. Mediator
Anwendung 1
Anwendung 2
Anwendung 1
Mediator
Data
Warehouse
Wrapper 1
ETL 3
ETL 1
Quelle 2
Wrapper 3
Wrapper 2
ETL 2
Quelle 1
Anwendung 2
Quelle 3
Quelle 1
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Quelle 2
Quelle 3
25
Vor- und Nachteile
Materialisiert
Virtuell
- (je nach Frequenz)
+
Antwortzeit
+
-
Komplexität
O
--
Anfragemächtigkeit
+
-
+/+
+/-
-
+
Zentral
Verteilt
+
-
Online-Zugriff
notwendig
Nein
Ja
Gesamt Zugriff
notwendig
Ja
Nein
Aktualität
Read/Write
Größe
Ressourcenbedarf
Datenreinigung
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
26
Inhalt dieser Vorlesung
• Multidatenbanksprachen
• SchemaSQL
•
•
•
•
•
Grundlegende Syntax
Zugriff auf Metadaten
Horizontale Aggregation
Dynamische Umstrukturierung
Implementierung
• Ausklang
•
•
Andere Multidatenbanksprachen
Pivot-Operator
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
27
Verteilung
Wdh: Multidatenbanken
Autonomie
Heterogenität
• Verteilt, autonom, und etwas heterogen
•
•
•
•
Keine technische und Datenmodellheterogenität
Z.B.: verteilte Systeme benutzen gleiche Techniken (RDBMS)
Schemata können strukturell und semantisch heterogen sein
Zugriff über einheitliche Sprache
• Autonomie bleibt bewahrt
•
Aber Zugriff muss möglich sein (Kommunikationsautonomie)
• Zentrales Thema: Multidatenbanksprache
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
28
Enge vs. lose Kopplung
User
• Enge Kopplung
•
Integriertes/föderiertes Schema
• Lose Kopplung
•
Kein integriertes Schema
• Nutzer müssen Semantik der
Quellen kennen
•
•
Überbrückung von Heterogenität
erfolgt durch Anfragen
Mächtige Anfragesprache
notwendig
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
29
Schematische Heterogenität
maenner( Id, vorname, nachname)
frauen( Id, vorname, nachname)
Relation vs. Wert
Relation vs. Attribut
person( Id, vorname, nachname,
maennlich?, weiblich?)
person( Id, vorname, nachname,
geschlecht)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Attribut vs. Wert
30
Strukturelle Heterogenität
• Unterschiedliche Modellelemente
•
•
•
Relation vs. Attribut
Attribut vs. Wert
Relation vs. Wert
• Zugriff auf Namen
•
•
•
Relationen
Attribute
Werte
• Unterschiedliche Verteilung von
Attributen
•
•
•
SchemaSQL
Z.B. Normalisiert vs. Denormalisiert
Fehlende/neue Attribute
Geschachtelt vs. Fremdschlüssel
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
SQL
31
Anforderungen an Multidatenbanksprachen
• Schemaunabhängigkeit
•
Struktur darf nicht Ausdrucksfähigkeit beeinflussen
• Umstrukturierungsmöglichkeiten
•
Anfrageergebnisse müssen neue Struktur erhalten können
• Verständlichkeit bei hoher Ausdrucksfähigkeit
• Abwärtskompatibilität mit SQL
• Einfach implementierbar
•
•
•
Möglichst ohne Veränderung des DBMS
Alle Anfragen müssen in SQL / Programme übersetzbar sein
Effiziente Ausführung
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
32
SchemaSQL
[LSS96, LSS99, LSS01]
• Erweiterung von SQL
•
•
•
Zugriff auf Tabellen in verschiedenen Schemata
Daten und Metadaten werden gleich behandelt
Umstrukturierungen innerhalb der Anfrage
• Daten zu Metadaten und umgekehrt
•
Dynamische Sicht-Definition
• Ergebnisrelation hängt vom Zustand der Datenbank ab
•
Horizontale Aggregation
• Über mehrere Spalten hinweg
•
Überbrückung struktureller Heterogenität
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
33
Einführendes Beispiel
• Ziel: Integrierte Sicht mit Schema der ersten Quelle
•
•
Alle Filmtypen der ersten Quelle sollen im Ergebnis vorhanden sein
Diese sind durch Werte von TYP definiert
CREATE
SELECT
FROM
UNION
SELECT
FROM
WHERE
VIEW q1_q2
id, title, regisseur, typ
q1.film
F2.id, F2.title, F2.regisseur, A
q1::Film F1, q2-> A, q2::Film F2
A = F1.Typ AND
F2.id = A.film_id
Iteriert über alle
Relationennamen von q2
Join über Attributwerte in q1 und
Tabellennamen in q2
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
34
Inhalt dieser Vorlesung
• Multidatenbanksprachen
• SchemaSQL
•
•
•
•
•
Grundlegende Syntax
Zugriff auf Metadaten
Horizontale Aggregation
Dynamische Umstrukturierung
Implementierung
• Ausklang
•
•
Andere Multidatenbanksprachen
Pivot-Operator
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
35
Ausdrucksfähigkeit von SQL
• Variablendeklaration in FROM Klausel
• Verwendung von Variablen in SELECT und WHERE Klauseln
• Implizites „FORALL“ über alle Tupel einer Relation
•
•
Joins: Geschachtelte Schleifen
Implementierung kann anders vorgehen (z.B. Sort-Merge bei Equi-Join)
Abkürzung bei Eindeutigkeit
<range>
<var>
<var> (alias)
Attribut
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
36
Grundlegende Syntax SchemaSQL
• Grundlegende Syntax wie SQL
• SELECT … FROM … WHERE
• Deklaration in FROM Klausel durch <range> <var>
• Variablen über fünf verschiedene Wertbereichstypen
•
•
•
•
•
->
db->
db::rel->
db::rel
db::rel.attr
Alle
Alle
Alle
Alle
Alle
Datenbanknamen der Multidatenbank
Relationennamen einer Datenbank db
Attributnamen einer Relation rel in db
Tupel einer Relation rel in db
verschiedenen Werte von attr in rel in db
• Weiterer Unterschied: Geschachtelte Deklarationen
•
•
Spätere Deklarationen der FROM Klausel referenzieren frühere
Machen Queries nicht gerade sehr gut lesbar
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
37
Beispiel
• Multidatenbank aus mehreren Universitätsdatenbanken
• univ-A, univ-B, univ-C, univ-D
• Information über Angestellte
•
•
•
Kategorie (category)
Gehalt (salFloor)
Abteilung (dept)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
38
SchemaSQL – Beispiel
Gleiche Semantik (salary)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
39
SchemaSQL – Beispiel
Gleiche Semantik (dept)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
40
SchemaSQL – Beispiel
Gleiche Semantik (category)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
41
Beispiel 1
• Gesucht
•
Alle Abteilungen in univ-A, die Technikern
mehr zahlen als gleiche Abteilungen in univ-B
• Anforderungen
•
•
•
Selektionen jeweils auf `Technician`
Vergleich der Gehälter
Join zwischen beiden Tabellen
• Verschiedene DBs
• Über welches Attribut?
->
alle Datenbanknamen
db->
alle Relationen in db
db::rel-> alle Attribute in rel (in db)
db::rel
alle Tupel in rel (in db)
db::rel.attr alle Werte von Attribut attr
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
42
Lösung
• Gesucht
•
Alle Abteilungen in univ-A, die Technikern
mehr zahlen als gleiche Abteilungen in univ-B
• SchemaSQL Anfrage
SELECT
FROM
WHERE
A.dept
univ-A::salInfo A,
univ-B::salInfo B,
univ-B::salInfo-> AttB
AttB <> `category`
A.dept = AttB AND
A.category = `Technician` AND
B.category = `Technician` AND
A.salFloor > B.AttB
Join zwischen
Attributnamen und
Spaltenwerten
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Alle
Attributnamen
43
Beispiel 2
• Gesucht
•
Alle Abteilungen in univ-C, die Technikern
mehr zahlen als gleiche Abteilungen in univ-D
• Anforderungen
•
•
•
Selektionen jeweils auf `Technician`
Vergleich der Gehälter
Join zwischen beiden Tabellen
• Verschiedene DBs
• Über welches Attribut?
->
alle Datenbanknamen
db->
alle Relationen in db
db::rel-> alle Attribute in rel (in db)
db::rel
alle Tupel in rel (in db)
db::rel.attr alle Werte von Attribut attr
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
44
Lösung
• Gesucht
•
•
Alle Abteilungen in univ-C, die Technikern mehr
zahlen als gleiche Abteilungen in univ-D
Tabellenname
SchemaSQL Anfrage
als Ausgabe
SELECT
FROM
WHERE
RelC
Geschach
univ-C-> RelC,
telte
univ-C::RelC C,
Variablen
univ-D::salInfo D
RelC = D.dept AND
C.category = `Technician` AND
C.salFloor > D.Technician
Iteration über
Tupel beider
Tabellen
in univ-C
Ulf Leser: Informationsintegration, Wintersemester
2008/2009
Join zwischen
Relationennamen
und Spaltenwerten45
Kartesische Produkte
SELECT
FROM
WHERE
RelC
univ-C-> RelC,
univ-C::RelC C,
univ-D::salInfo D
RelC = D.dept AND
C.category = `Technician` AND
C.salFloor > D.Technician
C
RelC
CS
MATH
[CS] Prof, 60.000
[CS] AssocProf, 55.000
[CS] Technician, 42.000
[MATH] Prof, 70.000
[MATH] AssocProf, 60.000
[MATH] Technician, 46.000
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
D
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45,000, 38.000
46
C
RelC
CS
MATH
CS
CS
CS
CS
CS
CS
MATH
MATH
MATH
MATH
MATH
MATH
Kartesische Produkte
Variable: D
[CS] Prof, 60.000
[CS] AssocProf, 55.000
[CS] Technician, 42.000
[MATH] Prof, 70.000
[MATH] AssocProf, 60.000
[MATH] Technician, 46.000
Prof, 60.000
Prof, 60.000
AssocProf, 55.000
AssocProf, 55.000
Technician, 42.000
Technician, 42.000
Prof, 70.000
Prof, 70.000
AssocProf, 60.000
AssocProf, 60.000
Technician, 46.000
Technician, 46.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
47
SELECT
FROM
RelC
univ-C-> RelC,
univ-C::RelC C,
univ-D::salInfo D
RelC = D.dept
C.category = `Technician`
C.salFloor > D.Technician
Kartesische Produkte
WHERE
AND
AND
CS
CS
CS
CS
CS
CS
MATH
MATH
MATH
MATH
MATH
MATH
Prof, 60.000
Prof, 60.000
AssocProf, 55.000
AssocProf, 55.000
Technician, 42.000
Technician, 42.000
Prof, 70.000
Prof, 70.000
AssocProf, 60.000
AssocProf, 60.000
Technician, 46.000
Technician, 46.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
48
SELECT
FROM
RelC
univ-C-> RelC,
univ-C::RelC C,
univ-D::salInfo D
RelC = D.dept
C.category = `Technician`
C.salFloor > D.Technician
Kartesische Produkte
WHERE
AND
AND
CS
CS
CS
MATH
MATH
MATH
Prof, 60.000
AssocProf, 55.000
Technician, 42.000
Prof, 70.000
AssocProf, 60.000
Technician, 46.000
CS, 75.000, 60.000, 40.000
CS, 75.000, 60.000, 40.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
MATH, 60.000, 45.000, 38.000
MATH, 60.000, 45.000, 38.000
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
49
SELECT
FROM
RelC
univ-C-> RelC,
univ-C::RelC C,
univ-D::salInfo D
RelC = D.dept
C.category = `Technician`
C.salFloor > D.Technician
Kartesische Produkte
WHERE
AND
AND
CS
MATH
Technician, 42.000
Technician, 46.000
CS, 75.000, 60.000, 40.000
MATH, 60.000, 45.000, 38.000
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
50
Einschub: Zugriff auf Metadaten?
• Liegen auch im Data dictionary (Katalog)
•
Alle Attributnamen und –typen im Schema
SELECT attribute_name, attribute_type, table_name
FROM user_attributes;
•
Alle Tabellennamen, alle Integritätsconstraints, alle Berechtigungen, …
• Können in Anfragen verwendet werden
•
[Oracle] Alle Tabellen, die ein Attribut enthalten,
dass denselben Namen hat wie ein
person(
Wert in person.geschlecht
Id, vorname, nachname,
maennlich, weiblich)
person( Id, vorname, nachname,
SELECT t.table_name
geschlecht)
FROM user_tables t, person p
WHERE t.attribute_name = p.geschlecht;
• Aber nur Umwandlung Metadaten -> Daten
•
Kein Zugriff auf die Tabellen „hinter“ den Metadatennamen
• Kein Standard
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
51
Einschub: Was sind Daten, was Metadaten?
• Universal database schema
•
Annahme: Datenbankweit eindeutige Tupel-IDs
tables( table_ name);
attribute( table_name, attribute_name, attribute_type);
tuple( table_name, tuple_id);
value( tuple_id, attribute_name, value);
• Kann alles ausdrücken, was ein beliebiges relationales
Schema ausdrücken kann
•
Erweiterungen für IC‘s, Datentypkonformität, …
• Schemaevolution wird zur Datenmanipulation
•
Neue Spalte: INSERT INTO attribute VALUES( …)
• Geeignet für semi-strukturierte Daten
•
Werte in value nur notwendig, wenn tatsächlich Daten vorhanden sind
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
52
Warum brauchen wir mehr?
• Vorteile
•
•
Sehr flexibel
Mächtiges Werkzeug für theoretische Untersuchungen
• Über alle relationalen Schemata
•
Einfach implementierbar
• Aber …
•
•
•
•
•
Konzeptionelle Verwirrung
Unverständlich – wo ist mein Schema? (meine Daten?)
Konsistenzhaltung wird extrem aufwändig
„Normale“ Anfragen werden extrem kompliziert: SELECT * FROM person
Schlechte Performanz
•
•
•
•
Alle Daten stehen in einer Spalte einer Tabelle
Keine separate Indexierung möglich
Keine differenzierte Selektivitätsabschätzungen möglich
…
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
53
Inhalt dieser Vorlesung
• Multidatenbanksprachen
• SchemaSQL
•
•
•
•
•
Grundlegende Syntax
Zugriff auf Metadaten
Horizontale Aggregation
Dynamische Umstrukturierung
Implementierung
• Ausklang
•
•
Andere Multidatenbanksprachen
Pivot-Operator
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
54
Herkömmliche Aggregation
• Funktionen
•
AVG, COUNT, SUM, MIN, MAX, (STDDEV, VARIANCE, …)
SELECT AVG(Budget) FROM projekt
• Gruppierung und Aggregation ist vertikal
•
Aggregation: Werte einer Spalte werden zusammengefasst
SELECT COUNT(*)
FROM
mitarbeiter
•
Gruppierung: Teilmengen von Werten einer Spalte werden
zusammengefasst
SELECT
FROM
WHERE
GROUP BY
m.id, SUM(p.Budget), MAX(p.Budget)
mitarbeiter m, projekt p
m.p_id = p.p_id
m.id
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
55
SchemaSQL – Aggregation 1
• Gesucht
•
Durchschnittliches Gehalt in
univ-B pro Kategorie für alle
Abteilungen
• Anforderungen
•
•
Durchschnittbildung über
Werte in zwei Spalten
Horizontale Aggregation
->
alle Datenbanknamen
db->
alle Relationen in db
db::rel-> alle Attribute in rel (in db)
db::rel
alle Tupel in rel (in db)
db::rel.attr alle Werte von Attribut attr
Liste von Listen
= implizite Semantik
SELECT
FROM
T.category, avg(T.D)
univ-B::salInfo-> D,
univ-B::salInfo T
WHERE
D <> `category`
GROUP BY T.category
Iteration über
alle Spalten
von salInfo
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Iteration über
alle Tupel von
salInfo
56
Horizontale Aggregation 2
• Gesucht
•
Durchschnittliches Gehalt in
univ-C pro Kategorie für alle
Abteilungen
• Anforderungen
•
•
Durchschnittbildung über zwei
Spalten
Die liegen in verschiedenen
Tabellen
->
alle Datenbanknamen
db->
alle Relationen in db
db::rel-> alle Attribute in rel (in db)
db::rel
alle Tupel in rel (in db)
db::rel.attr alle Werte von Attribut attr
SELECT
FROM
T.category, avg(T.salFloor)
univ-C-> D,
univ-C::D T
GROUP BY D.category
Iteration über
alle Relationen
von univ-C
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Iteration über
alle Tupel aller
Relationen
57
Blockweise Aggregation
• Durchschnittliches Gehalt in
univ-D aller Angestellten pro
Fakultät
• Anforderung
faculty
dname
fname
Math
MatNat II
Physics
MatNat I
CS
MatNat II
•
Aggregation über einen Block
SELECT F.fname, AVG(T.C)
FROM
univ-D::salInfo-> C,
univ-D::salInfo T,
univ-D::faculty F
WHERE C <> „dept“ AND
T.dept = F.dname
GROUP BY F.fname
->
alle Datenbanknamen
db->
alle Relationen in db
Aggregation über eine Liste von Listen
db::rel-> alle Attribute in rel (in db)
db::rel
alle Tupel in rel (in db)
Ulf Leser:
Wintersemester
2008/2009
58
db::rel.attr
alle Informationsintegration,
Werte von Attribut
attr