LOB, LOB Partition, LOB Subpartition, Materialized Views, Operator

Im siebten Teil der Reihe Objekttypen beginnen wir mit "L" wie LOB und weiteren LOB-bezogenen Objekttypen wie LOB Partition und LOB Subpartition. Außerdem stellen wir den Objekttyp Materialized View und den benutzerdefinierten Objekttyp Operator vor.

LOB Large Object

Der Objekttyp LOB speichert unstrukturierte textuelle oder binäre Daten, wie z. B. Grafiken oder Musikdateien, bis zu einer Größe von 128 Terabytes. Bei jeder Verwendung der internen Datentypen CLOB, BLOB, NCLOB und dem externen Datentyp BFILE wird ein Objekt vom Typ LOB erzeugt.

Create Table Wasserfall (
	Name Varchar2 (80),
	Photo BLOB,
	Beschreibung NCLOB,
	Lage CLOB,
	Webseite BFILE
);

Declare
 v_photo blob,
begin
 select photo
into v_photo 
from wasserfall
where name ='Tannary Wass';
end;

CREATE MATERIALIZED VIEW ONEWS 
TABLESPACE DB1
NOCACHE
NOLOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
USING INDEX
            TABLESPACE USERS
REFRESH FAST ON DEMAND
WITH PRIMARY KEY
AS 
SELECT * FROM ALL_OBJECTS;

CREATE MATERIALIZED VIEW onews_partition 
LOGGING
PARTITION BY RANGE (OWNER,OBJECT_NAME) 
SUBPARTITION BY HASH (OBJECT_NAME)
(  
  PARTITION OWNER VALUES LESS THAN (MAXVALUE, MAXVALUE)
    LOGGING
    NOCOMPRESS
  ( SUBPARTITION OWNER_SP1 )
)
NOCACHE
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
NEVER REFRESH
AS 
SELECT * FROM ALL_OBJECTS;

CREATE MATERIALIZED VIEW LOG ON EMP
NOCACHE
LOGGING
NOPARALLEL
WITH PRIMARY KEY
EXCLUDING NEW VALUES;

EMPNO  SNAPTIME$$  DMLTYPE$$  OLD_NEW$$  CHANGE_VECTOR$$
7893   01.01.2008  U          U          0400

CREATE OR REPLACE FUNCTION fn_contains(
stringin VARCHAR2, valuein VARCHAR2) RETURN NUMBER IS

BEGIN
 IF INSTR(stringin, valuein, 1, 1) = 0 THEN
	RETURN 0;
 END IF;

 RETURN 1;
END fn_contains;

CREATE OR REPLACE OPERATOR contains
BINDING(VARCHAR2, VARCHAR2) RETURN NUMBER USING fn_contains; 

SELECT *
FROM optab
WHERE contains(name, 'a') = 1;

Die folgende Auflistung beschreibt die Eigenschaften und Anwendungsbereiche der einzelnen LOB Datentypen:

• CLOB: In einem Character Large Object werden lange Texte gespeichert. Der Vorteil gegenüber VARCHAR2(...) liegt in der nahezu freien Größe. Der Datentyp VARCHAR2 ist auf 4000 Byte begrenzt. Oracle verwendet für den Zugriff von Anwendungsprogrammen auf LOBs so genannte Locatoren. Ein 2000 Zeichen langes LOB ist in der Regel langsamer zu verarbeiten als ein 2000 Zeichen langer VARCHAR2.
  
  
• BLOB: In den Binary Large Objects speichert man solche Anwendungsdaten, die vom Datenbanksystem nicht interpretiert, sondern nur gespeichert bzw. archiviert werden sollen. Der Datentyp BLOB ist der Nachfolger des Datentyps LONG RAW.
  
  
• NCLOB: Der NCLOB nimmt die Textdaten im Unicode nationalen Zeichensatz auf.
  
  
• BFILE: Die Daten eines Bfiles befinden sich in externen Dateien im Dateisystem. Auf BFILE Daten kann ausschließlich lesend zugegriffen werden.

In Abbildung 1 ist die Definition einer Tabelle aufgeführt, die jeweils eine Spalte der oben aufgeführten Datentypen enthält. Für den Zugriff auf die BLOB Spalte Photo wird, wie in der Abbildung 2 gezeigt, ein Locator erstellt.

LOB Partition, LOB Index

Einem internen LOB Objekt wird jeweils ein LOB Segment und ein LOB Index Segment zugeordnet. Diese beinhalten die physikalischen Strukturen des LOB Objekts. Wenn eine Tabelle, die ein LOB Objekt beinhaltet, partitioniert ist, so ist auch deren LOB Segment partitioniert. Dieses Segment wird dann als "LOB Partition" bezeichnet. LOB Partitions sind somit eigenständige Objekttypen im Sinne der View dba_objects. Gleiches gilt für Subpartitionen.

Es ist in diesem Zusammenhang interessant anzumerken, dass kein Segmenttyp LOB Index Partition existiert. Oracle markiert den partitionierten LOB Index als eine Index Partition. Sowohl LOB Partitionen, als auch LOB Subpartitionen sind eigene Objekttypen sowie auch Segmenttypen. Eine LOB Partition wird durch den Namen des LOBs (beispielsweise "SYS_LOB0000008121C00008$$"), den Parti- tionsnamen der Table (z. B. P0) und den LOB_Partition_Namen (z. B. "SYS_LOB_P1") gekennzeichnet. Der LOB_INDEX_Partition_Name lautet dann z. B. SYS_IL_P2.

Die folgenden Data Dictionary Views enthalten Informationen zu den LOB Objekten

• DBA_LOBS
• DBA_LOB_TEMPLATES
• DBA_LOB_PARTITIONS
• DBA_LOB_SUBPARTITIONS
• DBA_SEGMENTS

Details zur Verwendung von LOBs können Sie auch dem ORDIX News Artikel "LOB - Oracle Large Object" [1] entnehmen.

Materialized Views

Eine Materialized View (MV) ist ein Datenbankobjekt, welches die Ergebnismenge einer View zu einem bestimmten Zeitpunkt in einer eigenständigen Tabelle speichert. Materialized Views werden im Unterschied zu klassischen Views gewöhnlich nicht explizit in einer SQL-Query abgefragt. Durch das so genannte Query Rewrite bestimmt der Optimizer, ob der Zugriff auf eine Materialized View effizienter als auf deren Ursprungsdaten ist.

Die SQL-Query einer Materialized View (siehe Abbildung 3) bezieht sich auf Tabelle(n), View(s) oder weitere Materialized View(s). Zusammengenommen werden diese Objekte als Basistabellen (Begriff der Datenreplikation) oder auch als Detailtabellen (Begriff aus dem Datawarehouse-Bereich) bezeichnet.

Änderungen in den Basistabellen, auf die sich die Materialized Views beziehen, werden auf diese übertragen. Die Aktualisierung der Daten kann explizit auf Anweisung (on-demand) oder automatisch durchgeführt werden. Die Datenmenge kann vollständig (COMPLETE Refresh) oder nur auf die jeweiligen Datenänderungen bezogen sein (FAST Refresh).

Eine MV kann wie eine Tabelle (siehe Abbildung 4) partitioniert werden. Mit folgenden Paketen stehen Prozeduren zur Administration von MV zur Verfügung:

• DBMS_SNAPSHOT
• DBMS_MVIEW
• DBMS_SNAPSHOT_UTIL
• DBMS_OFFLINE_SNAPSHOT

Ein Materialized View Objekt ist mit einer internen Tabelle verknüpft, gegebenenfalls wird eine zusätzliche View erstellt. Oracle nutzt diese Objekte, um die Daten der Materialized Views zu verwalten. Zur Erstellung einer MV werden also die Berechtigungen zur Erstellung einer View vorausgesetzt.

Anwendungsgebiete von MVs

In Datawarehouse-Anwendungen werden Materialized Views als Ablage für berechnete (ggf. aggregierte) Daten genutzt, z. B. Umsatz pro Tag. Ein weiteres Einsatzgebiet ist die Daten-Replikation zwischen verteilten Datenbanken. Materialized Views können je nach Anwendung redundante Daten enthalten.

Eine MV wird als Simple bezeichnet, wenn ein Datensatz der MV auf einen Datensatz der Basistabelle(n) zurückgeführt werden kann. Eine MV wird als Complex MV bezeichnet, wenn ein Datensatz nicht auf einen Datensatz der Basistabelle(n) zurückgeführt werden kann (z. B. durch Aggregationen). Es handelt sich hierbei jedoch nicht um eigene Objekttypen, sondern um eine formale Unterscheidung, die aber Auswirkungen auf die möglichen Aktualisierungsverfahren hat.

Materialized View Logs dienen zur Speicherung aller Änderungen auf einer Tabelle. MV Logs dienen zur schnellen Bewirtschaftung von Materialized Views. MV Logs sind vom Objekttyp TABLE. Zu einer MV Log Tabelle wird mindestens ein Index erstellt. In Abbildung 5 ist ein Beispiel für die Erstellung einer MV Log aufgeführt, und Abbildung 6 zeigt einen Beispieldatensatz aus einer MV Logs Tabelle.

Folgende Views im Data Dictionary enthalten Informationen zu Materialized Views oder Materialized View Logs

• dba_registered_mviews
• dba_base_table_mviews
• dba_mviews
• dba_mview_aggregates
• dba_mview_comments
• dba_mview_detail_relations
• dba_mview_keys
• dba_mview_logs
• dba_mview_refresh_times

Weitere Informationen zu Materialized Views finden Sie in dem ORDIX News Artikel "DBMS_MVIEW - DBMS_SNAPSHOT" [2].

Operator Objekt

Ein Operator ist ein Objekttyp, mit dessen Hilfe benutzerdefinierte relationale oder logische, arithmetische Operatoren, wie z. B. eigene Berechnungen oder eigene Vergleiche, erstellt werden [3]. Ein Operator Objekt verweist auf eine Funktion, ein Package oder eine Prozedur, die beim Aufruf des Operators an dessen Stelle ausgeführt wird.

Ein benutzerdefinierter Operator ist domänenbezogen, er kann also nur mit dafür vorgesehenen Datentypen genutzt werden. Die Funktionsweise eines benutzerdefinierten Operator Objektes soll anhand des folgenden Beispiels näher erläutert werden:

create operator <Operatorname>
binding (<Datentypliste>)
return <Datentyp>
using <Funktionsname>;

Operatoren werden in zwei Schritten implementiert. Zunächst ist eine PL/SQL-Routine zu schreiben, die die gewünschte Funktion ausführt. Eine solche ist z. B. eine Funktion fn_contains, die überprüft, ob ein String in einem anderen String enthalten ist. Anschließend ist ein Datenbankobjekt vom Typ Operator anzulegen, das dem Datenbank-Server die definierte Funktion als Operator auf einen neuen Datentyp erklärt.

In Abbildung 7 ist die Funktion fn_contains aufgeführt, die überprüft, ob ein String in einem anderen String enthalten ist. In der Abbildung 8 wird ein benutzerdefinierter Operator contains erstellt, der mit der Funktion fn_contains verknüpft ist. In der Abbildung 9 ist aufgeführt, wie der neue Operator in einer WHERE-Klausel eingesetzt wird.

Der Funktionsname ist dabei der Name der zuvor definierten PL/SQL-Routine, deren Signatur natürlich mit der hier angegebenen übereinstimmen muss. Diese Deklaration ist erforderlich, damit benutzerdefinierte Indexe und Anfrageoptimierungen vom Datenbank-Server verwendet werden können.

Operatoren kommen im Umfeld des ODCI (Oracle Data Cartridge Interface) zum Einsatz. Hiermit können komplexe Datentypen wie z. B. geographische Daten (Oracle Spatial) indiziert werden. Für alltägliche Datentypen werden normalerweise keine Operatoren benötigt.

Die Data Dictionary Views dba_operators und dba_operator_comments enthalten Informationen zu benutzerdefinierten Operatoren. In der View dba_operators ist aufgelistet, über welche Anzahl von Bindungen ein Operator verfügt.

Zur Administration von Operatoren werden folgende Berechtigungen benötigt:

• create any operator
• create operator
• drop any operator
• execute any operator

Die Reihe Objekttypen von A - Z werden wir in einer der nächsten ORDIX News fortsetzen.

Seitenanfang

Seite drucken

Seite weiterempfehlen