Home 
ORDIX News 1/2007 Datenbanken
ORDIX News 1/2007 Datenbanken
ORDIX News 1/2007 Datenbanken
Datenbank-, System-| XQuery Steht für "XML Query Language" und ist eine Abfragesprache für XML-Daten aus einer Datenbank. |
| W3C Auch "World Wide Web Consortium" genannt. W3C ist ein Gremium zur Standardisierung für World Wide Web betreffende Techniken, wie zum Beispiel HTML und XML. |
Die interessanten Neuerungen des Datenbankservers betreffen die Bereiche:
Ab der Version 9.1 können mehrere DB2-Installationen und Fix Packs der gleichen Version auf einem System installiert werden. Bisweilen war an eine Koexistenz nicht zu denken, da der Installationspfad des Datenbanksystems fest vorgegeben war.
Im Installationsprozess der neuen Version hingegen kann der DBA das Verzeichnis selbst auswählen.
In der Vergangenheit war es lediglich möglich, verschiedene DB2-Versionen (7, 8, ...) auf einem System zu installieren. Probleme gab es bei den älteren Versionen aber, wenn Unterversionen oder Fix Packs installiert werden sollten.
Um diese zu umgehen, musste man sich so genannter "Alternate Fix Packs" bedienen, die in andere Verzeichnisse installiert werden konnten. Mit den Standard CDs und Fix Packs war dies allerdings nicht erlaubt.
Für Unix-Systeme wurde das DB2-Imageformat auf .tar.gz geändert. Das hat zur Folge, dass Dienstprogramme wie pkgadd oder rpm nicht mehr genutzt werden können, um sich installierte DB2-Produkte anzeigen zu lassen. Stattdessen wurde der DB2-Befehl db2ls eingeführt. Ab der Version 9.1 ist dies die einzige Möglichkeit, um installierte DB2-Produkte abfragen zu können (siehe Abbildung 1).
inst91@admiral:/home/inst91 # db2ls Install Path Level Fix Pack Special Install Number Install Date --------------------------------------------------------------------------------- /opt/db2/V9.0 9.0.0.0 0 Tue Aug 1 02:51:31 2006 /opt/db2/V9.1 9.1.0.0 0 Tue Aug 1 03:07:05 2006 |
| Abb. 1: Der Befehl db2ls zum Abfragen von installierten DB2-Produkten. |
Auf Windows-Systemen ist eine Installation nun auch ohne die Administrator-Berechtigung möglich. Hierzu kann man die Windows XP Betriebssystem-Funktion für die "erweiterten Zugriffsrechte" nutzen und die Installation einem "Hauptbenutzer" oder einem "eingeschränkten Benutzer" erlauben.
 |
| Abb. 2: ROW COMPRESSION zum Komprimieren einzelner Zeilen in einer Datenbanktabelle. |
Die interessanteste Neuerung im Bereich Performance ist die so genannte ROW COMPRESSION. Sie erlaubt es, einzelne Zeilen einer Datenbanktabelle zu komprimieren.
Diese neue Komprimierungsmethode ist Wörterbuch-basiert. Für die Komprimierung bzw. Dekomprimierung von Daten werden intern symbolische Tabellen verwendet, die gemeinsame Sequenzen von aufeinander folgenden Bytes von Zeilen speichern. Dadurch muss ein mehrmals vorkommender Wert nur einmal gespeichert werden (siehe Abbildung 2).
Mit der Version 9.1 wurde die Option RESTRICTIVE für die CREATE DATABASE-Anweisung eingeführt. Durch diesen Schalter kann verhindert werden, dass die Standard Zugriffsrechte createtab, bindadd, connect und implicitschema für die Gruppe public beim Anlegen einer Datenbank automatisch vergeben werden.
CREATE DATABASE DBV91 RESTRICTIVE;
Der einzige, der dann Zugriff auf die Datenbank hat, ist der Ersteller selbst. Alle weiteren, gewünschten Berechtigungen und Zugriffsrechte müssen vom Eigentümer explizit vergeben werden.
Bei der Version 8 konnten Benutzer mit DBADM- oder SYSADM-Berechtigung unter Verwendung des SET SESSION AUTHORIZATION-Kommandos beliebig Identitäten wechseln und unter einer anderen Benutzer-ID arbeiten. Durch die neue SETSESSIONUSER-Berechtigung wird diese Freiheit genommen.
Nun dürfen nur noch Benutzer, die über eine SETSESSIONUSER-Berechtigung verfügen, einen solchen "Identitätswechsel" zur ihnen freigegebenen User-ID durchführen.
Um allerdings die Abwärtskompatibilität zu gewährleisten, bekommen Benutzer mit DBADM-Berechtigung nach der Migration auf die neue Version automatisch die SETSESSIONUSER-Berechtigung für die Gruppe public erteilt.
Die SECADM-Berechtigung zählt ebenfalls zu den Neuerungen und steht sehr eng im Zusammenhang mit der LBAC-Funktion (s. u.). Zur Konfiguration von LBAC ist diese Berechtigung nämlich zwingend erforderlich.
Zusätzlich erlaubt diese Qualifikation, die Eigentumsrechte von Datenbankobjekten zu ändern und die SETSESSIONUSER-Berechtigung zu vergeben.
Die SECADM-Berechtigung selbst kann nur vom Eigentümer einer Datenbank vergeben werden. Auch Benutzer, die anderen administrativen Gruppen (DBADM, SYSADM) zugeordnet sind, dürfen dieses Recht nicht vergeben.
 |
| Abb. 3: LBAC-Security ermöglicht den Zugriff. |
LBAC steht für "Label Based Access Control" und ermöglicht die Vergabe von Lese- und Schreibzugriffsrechten für einzelne Zeilen oder Spalten einer Datenbanktabelle.
Dabei werden sowohl Zeilen und Spalten als auch Benutzern so genannte "security labels" zugewiesen.
Möchte ein Benutzer dann auf Datensätze zugreifen, so wird sein "security label" mit dem der Datensätze verglichen und er bekommt nur solche angezeigt, bei denen eine Übereinstimmung vorhanden ist. Bei allen anderen Datensätzen sieht es für den Benutzer so aus, als ob diese nicht vorhanden wären.
Die einzelnen "security labels" werden einer so genannten "security policy" zugewiesen, die wiederum Bestandteil einer Tabelle ist. Dabei gilt es zu beachten, dass eine Tabelle immer nur eine "security policy" besitzen kann. Abbildung 3 zeigt eine vereinfachte Darstellung.
Automatisierung bedeutet für den DBA weniger Administrationsaufwand. Mit DB2-Version 9.1 soll das mit zusätzlichen Erweiterungen zu den bereits bestehenden Automatismen erreicht werden.
So nimmt der Datenbankserver zum Beispiel selbstständig Konfigurationsanpassungen im Bereich der Speicherverwaltung und des Bufferpools vor oder aber erstellt automatisch Statistiken über das Datenbanksystem, auf die der DBA dann zugreifen kann.
Hinter der Tabellenpartitionierung verbirgt sich die Speicherung von Tabellendaten in mehr als einem Speicherobjekt (Partition). Aufgrund des Inhaltes einer Spalte erfolgt dann die Zuweisung des Datensatzes zu einer Partition.
Dem DBA soll somit die Verwaltung von besonders großen Datenbanken erleichtert werden. Eine Tabelle mit Umsatzzahlen kann so zum Beispiel in vier Partitionen unterteilt werden, so dass jede der Partitionen logischerweise die Umsatzzahlen eines Quartals aufnehmen würde.
Der Vorteil von partitionierten Tabellen besteht in der Regel darin, bei Datenbankabfragen ein schnelleres Ergebnis zu liefern, da nicht gewünschte Daten eventuell erst gar nicht durchsucht werden. Abhängig ist dies natürlich von der where-Bedingung des SQL-Statements.
Zusätzlich kann die Tabellenpartitionierung auch mit bereits bestehenden Datenorganisationsschemata, z. B. mit der Datenpartitionierungsfunktion (DPF) oder mit mehrdimensionalem Clustering (MDC) kombiniert werden, um eine noch bessere Leistung der Datenbank zu erzielen.
 |
| Abb. 4: Datenmodelle im Vergleich. |
In Sachen Architektur hat sich in der neuen Version einiges geändert. Neben dem relationalen Datenmodell existiert nun ein zusätzliches XML-Datenmodell, das die Speicherung von XML-Daten innerhalb einer Datenbank auf eine neue Art und Weise ermöglicht.
Bislang gab es zwei Optionen zum Speichern von XML-Daten:
Das XML-Datenmodell basiert auf dem neuen Datentyp XML. DB2 bietet die Möglichkeit, eine Tabellenspalte von eben diesem XML-Typ zu deklarieren. Innerhalb einer solchen Spalte werden XML-Daten dann nicht als .xml-Datei, sondern in "geparster" Form in einer Baumstruktur abgelegt (siehe Abbildung 4).
Bei XQuery handelt es sich um eine Abfragesprache für XML-Daten, die vom W3C entwickelt worden ist. IBM verwendet diese Abfragesprache in DB2 9.1, um Daten, die vom Datentyp XML gespeichert wurden, aus der Datenbank ermitteln zu können.
Neben der enormen Flexibilität bietet XQuery zusätzlich den Vorteil, dass diese Sprache zusammen mit bzw. parallel zu SQL verwendet werden kann. Dadurch kann zum einen auf die ebenfalls flexible XML-Struktur zugegriffen werden. Zum anderen besteht die Möglichkeit, relationale Daten mit XML-Daten zu mischen.
Während der Abfrage selbst nimmt eine Sprache die Position der Primärsprache ein, die andere wird Sekundärsprache. Die Reihenfolge, ob zuerst XQuery oder SQL, ist jedem selbst überlassen. Zu beachten gilt es allerdings, dass XQuery im Gegensatz zu SQL case-sensitive ist.
|
| Abb. 5: Diverse, weitere Neuerungen. |
Neben den vielen kleineren Erweiterungen sind der Datentyp XML und die damit verbundenen, neuen Abfragemethoden "XQuery" und "SQLX" mit Sicherheit die Bereiche, die das meiste Interesse auf sich ziehen werden. Ob sich XML als Format für die Datenspeicherung innerhalb von Datenbanken behaupten kann, bleibt jedoch abzuwarten.
Wie bereits erwähnt, war dieses nur ein erster Überblick über die Neuerungen in DB2. Es gibt noch zahlreiche weitere, interessante Implementierungen (siehe Abbildung 5). Hierzu jedoch mehr in einer der kommenden Ausgaben. Dann erfahren Sie Details zu den Neuerungen sowie technische Hintergründe zu den neuen Funktionen.
Sie wünschen vorab weitere Informationen zur IBM DB2 Version 9.1? Sprechen Sie uns an!
Thorsten Schuhmacher (info@ordix.de).