Übungsklausuren 3/4

Eine logische Sicht auf Dateien realisieren Betriebssysteme mit Hilfe von hierarchischen Verzeichnissen (Ordnern). Eine logische Sicht auf Daten realisieren Datenbanksysteme z.B. mit Hilfe von zeilenorientierten Konzepten (relationale DBS). In beiden Fällen muss die physische Organisation dem Benutzer nicht bekannt sein, um mit den Dateien bzw. Daten zu arbeiten (Transparenz durch die Trennung der physischen und logoschen Ebene > ANSI/SPARC-Modell).

Eine sukkzessive Erweiterung der Hardware durch weitere Serverknoten (scaling-out) ist aus verschiedenen Gründen in der Praxis nicht realisierbar. Es scheitert bereits daran, dass kompatible Hardware nicht mehr erhältlich ist. Diese Einschränkung kann durch eine Virtualisierungsebene überwunden werden.

Syntax: Left-Semi-Join Operation mit Benennung der Abfrage durch die Zuweisung "=". projekt und abteilung10 sind Tabellennamen.

Semantik: Es wird ein Natural-Join ausgeführt, wobei in der Ergebnismenge jedoch nur die Spalten (Attribute) der Tabelle (Relation) projekt enthalten sind. Die Benennung der Abfrage entspricht der Definition einer View.

Pivot-Abfrage, z.B. mittels standardisierter Pivot-Klausel einer SELECT-Anweisung.

Zusatzfrage: Spaltenorientierung

Eine Untersuchung von SAP (2010) zeigte, dass auch in OLTP-Systemen überwiegend Abfragen durchgeführt werden. Bei Abfragen sind spaltenorientierte Strukturen vorteilhafter.

(1) def (2) Das DBMS wird bei Oracle als Instanz bezeichnet. (3) Das Kommando ist identisch.

Mit Hilfe des logischen Datenbankobjekts "Tablespace". Es realisiert quasi die Schnittstelle zwischen der logischen und physischen Ebene des ANSI/SPARC-Architekturmodells.

Die dauerhafte Speicherung (durch Kopieren) der Online Redolog-Dateien. Dies findet bei jedem Wechsel zwischen Redolog-Gruppen (gespiegelte Online Redolog-Dateien) statt. Eine Online Redolog-Datei darf erst überschrieben werden, wenn die Archivierung dieser Online Redolog-Datei abgeschlossen ist.

In der Mount-Phase (also nach dem Lesen der Kontrolldatei) ist dem DBMS (und somit RMAN) bekannt, wo sich die Dateien befinden. Die Dateien sind jedoch nicht geöffnet, d.h. Benutzer können nicht arbeiten. Das DBS ist also nicht "online".

3.

Durch das MVCC-Verfahren kann die Operationen r12(x) virtuell zeitlich verschoben werden vor die Schreiboperation w31(x), weil der alte Wert von x gelesen werden kann. Ebenso wäre auch eine Verschiebung von r32(z) vor w22(z) möglich. Es sind daher verschiedene konfliktäquivalente serielle Schedules denkbar, je nach dem, welche Transaktion beginnt. Würde T1 beginnen, dann wäre die Operation r12(x) vor w31(x) unter Berücksichtigung von MVCC also kein veränderter Konflikt. Ebenso r32(z) vor w22(z). Der konfliktäquivaltente serielle Schedule wäre daher T1-T3-T2. T2 kann nicht beginnen, denn w21(y) müsste dann vor r11(y) stattfinden, was MVCC nicht bewirken kann und somit ein veränderter Konflikt wäre. Unter der Annahme, dass der Ablauf wie in a.) mit T3 beginnen soll, könnte durch MVCC aber wie zuvor beschrieben r32(z) vor w22(z) erfolgen. Dann müsste T1 folgen und schließlich T2. Die Operation r12(x) würde dabei den aktuellen Wert von x lesen, weil T3 beendet werden kann. Die konfliktäquivalente serielle Abfolge wäre dann also T3-T1-T2 mit dem folgendem Konfliktgraphen:

4.

"Lesekonsistenz ohne Sperren" mit Hilfe von Undo-Segmenten (Rollback-Segmenten).

{} unsortierte Menge [] sortierte Menge

Fakten

Allgemein wird zwischen Maßzahlen (measures) und Kennzahlen unterschieden. Maßzahlen sind Messwerte, aus denen Kennzahlen gfls. mittels mathematischer Operationen abgeleitet werden. Maßzahlen sind “Fakten“. Somit: Cube VERKAUF mit einzelpreis und menge, Cube LAGER mit bestand sowie Cube LIEFERUNG mit pakete.

Anm.: In Anlehnung an den Begriff “Faktentabelle“ im Rahmen der Realisierung mit RDBS werden Cubes+Measures manchmal auch als Fakten bezeichnet. Darüberhinaus gibt es auch Quellen, in denen quasi eine Zelle des Cube als Fakt bezeichnet wird, die alle Measures/Kennzahlen bezüglich der geringsten Granularität (Aggregationsstufe) beinhaltet. Dies entspricht im Prinzip einem sogenannten “Fakt-Record“ einer Faktentabelle.

Cube = (Kennzahlmenge, Dimensionenschema)

VERKAUF = (Mverkauf, DSverkauf)

LAGER = (Mlager, DSlager)

LIEFERUNG = (Mliefer, DSliefer)

Dimensionenschema = Schema einer Dimension

Dimensionenschemata

DSverkauf = {Kunde, Produkt, Zeit}

DSlager = {Produkt, Zeit}

DSliefer = {Kunde, Zeit}

Klassifikationshierarchien als sortierte Mengen von Dimensionselementen

(Dimensionselement = Stufe in einer Klassifikationshierarchie)

Kunde = [knr, land, region, gesamt]

Produkt = [pnr, bezeichnung, kategorie, gesamt]

Zeit = [tag, monat, quartal, jahr, gesamt]

Zeit = [tag, woche, jahr, gesamt] /*multiple (parallele) Hierarchie*/

Annahmen:

· Verschiedene Produkte (pnr) können gleiche Bezeichnungen haben.

· Woche im Sinne einer Kalenderwoche. Diese gehört genau zu einem Jahr.

Ergänzung:

Die oberste Hierachiestufe gesamt enthält die Aggregation auf einen einzelnen Wert für die gesamte Dimension.

Dimensionale Attribute

knr - -> name

Die Hierarchiestufen knr und pnr sind nicht sehr aussagekräftig und gehören mehr zum DFM-Konzept. Besser wären die Bezeichnungen kunde und produkt mit den dimensionalen Attributen knr und pnr. Die Bezeichnungen der Hierarchiestufe mit geringstenr Granularität (Primärattribut) ist aber nicht zwingend die Bezeichnung der Dimension. Nicht verwechseln. Bei der ADAPT-Notation wird dies unterschieden. Sinnvolle Bezeichnung der Dimension wäre Produkt und Artikel für das Primärattribut.

Hinweise:

· Es sind verschiedene Lösungen möglich und z.B. nicht zwingend das Mondrian-Format gefordert (keine Tabellennamen).

· Sehr viel Schreibarbeit. In der Klausur gab es die max. Punktzahl, wenn das Grundprinzip korrekt erkennbar war.

  <schema>

    <cube name="VERKAUF">

      <kennzahl>einzelpreis</kennzahl>

      <kennzahl>menge</kennzahl>

      <cube_dimension>kunde</cube_dimension>

      <cube_dimension>produkt</cube_dimension>

      <cube_dimension>zeit</cube_dimension>

    </cube>

    <cube name="LIEFERUNG">

      <kennzahl>pakete</kennzahl>

      <cube_dimension>kunde</cube_dimension>

      <cube_dimension>zeit</cube_dimension>

    </cube>

    <cube name="LAGER">

      <kennzahl>bestand</kennzahl>

      <cube_dimension>produkt</cube_dimension>

      <cube_dimension>zeit</cube_dimension>

    </cube>

    <dimension name="kunde">

      <hierarchie>

        <level>knr</level>

          <attribute>name</attribute>

        <level>land</level>

        <level>region</level>

        <level>gesamt</level>

      </hierarchie>

    </dimension>

    <dimension name="produkt">

      <hierarchie>

        <level>pnr</level>

        <level>bezeichnung</level>

        <level>kategorie</level>

        <level>gesamt</level>

      </hierarchie>

    </dimension>

    <dimension name="zeit">

      <hierarchie>

        <level>tag</level>

        <level>monat</level>

        <level>quartal</level>

        <level>jahr</level>

        <level>gesamt</level>

      </hierarchie>

      <hierarchie>

        <level>tag</level>

        <level>woche</level>

        <level>jahr</level>

        <level>gesamt</level>

      </hierarchie>

    </dimension>

  </schema>

for $i in fn:doc("schema.xml")

return $i/schema/cube/kennzahl/text()

Result Sequence

-----------------

einzelpreis

menge

pakete

bestand

Hinweise:

Die Funktion text() bewirkt, dass nur der jeweilige Inhalt des Tags zurückgegeben wird und nicht das gesamte Tag <kennzahl>. . . </kennzahl>

Das Modell wurde in ähnlicher Weise im Mondrian-Format in der XML-Datenbank von Oracle (XDB) gespeichert. Hier ist der Name der Kennzahl ein Tag-Parameter. Abfrage in SQL*Plus:

connect scott/tiger@heron_stud112

xquery for $i in fn:doc("/public/dbu/projektskizze.xml")

return $i/Schema/Cube/Measure/@name

“Enterprise Information Bus“ (EIB) von Ralph Kimball

Die Trennung zwischen OLTP (Online Transactional Processing) und OLAP (Online Analytical Processing). Spaltenorientierung eignet sich besonders für OLAP und ist Voraussetzung für Hauptspeicherdatenbanken. Eine Untersuchung zeigte, dass auch bei OLTP meist Abfragen (wie bei OLAP) durchgeführt werden!

Relationale Datenbanksysteme sind zeilenorientiert. >> Plattner, Datenbank-Spektrum (2010):

Syntax: HTML und XML ist hierarchisch mit Auszeichnungselementen (Markups) aufgebaut. Bei HTML sind diese vordefiniert, bei XML sind sie frei definierbar.

Semantik: HTML hat den Zweck, Inhalte formatiert darzustellen. Semantik wird durch eine sinnvolle Gliederung einer Seite erreicht. XML hat dagegen den Zweck, Daten zu speichern. Die Bedeutung (Semantik) ist durch die Struktur der Daten vorgegeben (Information), die durch sinnvolle Markups umgesetzt werden muss (XML Schema).

Inkrementelle Backups sparen Speicherplatz. Sie sind zudem schneller und benötigen daher ein kleineres Zeitfenster. Jedoch dauert das Restore länger.

dbca: database configuration assistant. DBS=DBMS+DB. Datenbankmanagementsystem (Instanz) und Datenbank (Dateien).

shutdown abort beendet die Instanz durch "Abschießen" der Prozesse (inkonsistenter Zustand des DBS). Dagegen wird bei shutdown immediate ein Checkpoint durchgeführt, d.h. Transaktionen werden beendet und Daten werden in die Datendateien geschrieben (konstistenter Zustand des DBS), daher ist dies viel langsamer.

1. Embedded Database ist für kleinere Systeme gedacht. Plugable Database beinhaltet volle Fuktionalität (Enterprise Edition).

2. Embedded Database gibt es Open Source (z.B. Java). Plugable Database wird derzeit ausschließlich kommerziell abgeboten.

3. Embedded Database wird in ein Gesamtsystem integriert. Plugable Database wird an ein Basissystem angedockt.

i=internet, g=grid, c=cloud

S ist nicht serialisierbar wegen dem Zyklus T1-T2-T1. Begründung: T1 kann nicht zugleich vor und auch nach T2 erfolgen. Entweder oder!

3.

Durch das MVCC-Verfahren können die Operationen r21(y), r31(y) und r12(x) virtuell zeitlich verschoben werden. Diese Leseoperationen befinden sich dann vor den jeweiligen Schreiboperationen. r21(y) findet dadurch virtuell vor w11(y) statt, da der alte Zustand von y gelesen wird. Es folgt w22(x) und T2 kann somit abgeschlossen werden. r31(y) muss ebenso den alten Zustand von y lesen, weil y noch nicht freigegeben ist. Die Reihenfolge der Transaktionen daher:

"Lesekonsistenz ohne Sperren" mit Hilfe von Undo-Segmenten (Rollback-Segmenten).

PK (Primärschlüssel)=blau, FK (Fremdschlüssel)=rot

sales(time_key,item_key,branch_key,location_key,

euros_sold,units_sold)

shipping(item_key,time_key,shipper_key,from_location,to_location,

euros_cost,units_shipped )

branch(branch_key,branch_name,branch_type)

location(location_key,street,city,province_or_state,country)

item(item_key,item_name,brand,type,supplier_key)

shipper(shipper_key,shipper_name,location_key,shipper_type)

time(time_key,day,day_of_week,month,year)

Hinweise:

1. supplier_key ist kein FK. Es existiert keine Tabelle namens supplier.

2. Rechtzeitig eine neue Zeile beginnen!

Kennzahlen: euros_sold, units_sold, euros_cost, units_shipped

Dimensionen: Branch, Location, Item, Shipper, Time

Cubes

SALES = (Msales, DSsales)

SHIPPING = (Mshipping, DSshipping)

Dimensionenschemata

DSsales = {Item,Branch,Location,Time}

DSshipping = {Item,Shipper,Location(from),Location(to),Time}

Klassifikationshierarchien als sortierte Mengen von Dimensionselementen

(Dimensionselement = Stufe in einer Klassifikationshierarchie)

Branch = [branch, type, all]

Item = [item, type, gesamt]

Location = [location, street, city, province, country, all]

Shipper = [shipper, type, all]

Time = [time_key, day, day_of_week, month, year, all]

Dimensionale Attribute

item - -> name

branch - -> name

shipper - -> name

day - -> day_of_week

Hinweise:

1. Überkreuzung von Verbindungslinien lässt sich nicht immer vermeiden. Es muss aber gekennzeichnet werden, dass es keine Verzweigung ist.

2. In der Klausur war das Zeichnen des Diagramms ein Zeitproblem. Es wird dann aber recht großzügig korrigiert. Wichtig: Zwei Cubes und gemeinsame Referenzierung von Dimensionen.

SELECT t.month "",

ROUND(t.SUM(s.euros_sold))/1000 OVER (ORDER BY t.month

ROWS BETWEEN 3 PRECEDING AND 3 FOLLOWING) "Sales($000)"

FROM time t, sales s

WHERE t.time_key=s.time_key ;

Ebenso mit 5 Zeilen vor und danach.

Galaxienschema