DB2 Universal Database - Systemverwaltung


Erstellen und Auffüllen einer Tabelle

Wenn festgelegt ist, wie die Daten in Tabellen organisiert werden sollen, besteht der nächste Schritt darin, diese Tabellen mit der Anweisung CREATE TABLE zu erstellen. Die Tabellenbeschreibungen werden im Systemkatalog der Datenbank, mit der Sie verbunden sind, gespeichert.

Eine detaillierte Beschreibung der Syntax der Anweisung CREATE TABLE finden Sie im Handbuch SQL Reference. Informationen zum Erstellen einer Übersichtstabelle finden Sie in Erstellen einer Übersichtstabelle. Informationen zur Benennung von Tabellen, Spalten und anderer Datenbankobjekte finden Sie in Anhang A, Namenskonventionen.

Durch die Anweisung CREATE TABLE werden der Tabelle ein Name, der ein qualifizierter oder nicht qualifizierter Bezeichner sein kann, und eine Definition für jede der enthaltenen Spalten gegeben. Jede Tabelle kann in einem separaten Tabellenbereich gespeichert werden, so daß ein Tabellenbereich nur eine Tabelle enthält. Wenn eine Tabelle häufig gelöscht und wieder erstellt wird, ist es effizienter, sie in einem separaten Tabellenbereich zu speichern und dann den Tabellenbereich anstelle der Tabelle zu löschen. Es können auch mehrere Tabellen in einem einzigen Tabellenbereich gespeichert werden. In einer partitionierten Datenbankumgebung definiert der ausgewählte Tabellenbereich außerdem die Knotengruppe und die Datenbankpartitionen, in denen die Tabellendaten gespeichert werden.

Zu Beginn enthält die Tabelle keine Daten. Um der Tabelle Zeilen mit Daten hinzuzufügen, haben Sie folgende Möglichkeiten:

Einzelheiten zum Verschieben von Daten in und aus Tabellen finden Sie in Versetzen von Daten Dienstprogramme und Referenz.

Daten können zu einer Tabelle hinzugefügt werden, ohne die Änderungen zu protokollieren. Mit der Klausel NOT LOGGED INITIALLY der Anweisung CREATE TABLE kann verhindert werden, daß die an der Tabelle vorgenommenen Änderungen protokolliert werden. Alle Änderungen an der Tabelle durch die Operationen INSERT, DELETE, UPDATE, CREATE INDEX, DROP INDEX und ALTER TABLE in derselben Arbeitseinheit, in der die Tabelle erstellt wird, werden nicht protokolliert. Das Protokollieren beginnt in den nachfolgenden Arbeitseinheiten.

Eine Tabelle besteht aus einer oder mehreren Spaltendefinitionen. Es können maximal 500 Spalten für eine Tabelle definiert werden. Die Spalten stellen die Attribute einer Entität dar. Die Werte jeder Spalte gehören jeweils demselben Datentyp an. Weitere Informationen finden Sie im Handbuch SQL Reference.

Anmerkung:Der Maximalwert von 500 Spalten gilt, wenn eine Seitengröße von 4 KB verwendet wird. Bei einer Seitengröße von 8 KB, 16 KB oder 32 KB beträgt der Maximalwert 1012 Spalten.

Zu einer Spaltendefinition gehören ein Spaltenname, ein Datentyp und jedes erforderliche Nullattribut bzw. ein (wahlfrei vom Benutzer gewählter) Standardwert.

Der Spaltenname beschreibt die Informationen, die in der Spalte enthalten sind, und sollte leicht verständlich sein. Er muß innerhalb der Tabelle eindeutig sein. Jedoch kann derselbe Name auch in anderen Tabellen verwendet werden. Informationen zu Benennungsregeln finden Sie in Objektnamen.

Der Datentyp einer Spalte definiert die Länge der enthaltenen Werte und die Art von Daten, die für die Spalte gültig sind. Der Datenbankmanager unterscheidet die Datentypen für Zeichenfolgen, numerische Daten, Datum, Uhrzeit und LOB (großes Objekt). Datentypen für Grafikzeichenfolgen sind nur für Datenbankumgebungen gültig, in denen Mehrbytezeichensätze verwendet werden. Darüber hinaus können für Spalten benutzerdefinierte Datentypen (UDT - User-defined Distinct Type) definiert werden. Eine Beschreibung dieser Datentypen finden Sie in Erstellen eines benutzerdefinierten Datentyps (UDT).

Mit dem Attribut DEFAULT wird definiert, welcher Wert zu verwenden ist, wenn kein Wert für die Spalte angegeben wird. Der Standardwert (DEFAULT) kann angegeben werden, oder es kann ein vom System definierter Standardwert verwendet werden. Standardwerte (DEFAULT-Attribute) können für Spalten mit und ohne Angabe des Nullattributs definiert werden.

Das Nullattribut gibt an, ob eine Spalte Nullwerte enthalten kann oder nicht.

Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Tabelle zu erstellen:
  1. Erweitern Sie die Sicht der Objektbaumstruktur so lange, bis der Ordner Tabellen angezeigt wird.
  2. Klicken Sie mit der rechten Maustaste auf dem Ordner Tabellen und wählen Sie dann im Kontextmenü Erstellen --> Tabellen mit Assistent aus.
  3. Führen Sie die im Assistenten aufgeführten Schritte aus, um die Tasks abzuschließen.

Geben Sie in der Befehlszeile folgendes ein, um eine Tabelle zu erstellen:

   CREATE TABLE <NAME>
      (<spaltenname>  <datentyp>  <nullattribut>)
      IN <TABLE_SPACE_NAME)

Das folgende Beispiel zeigt eine Anweisung CREATE TABLE, mit der die Tabelle EMPLOYEE im Tabellenbereich RESOURCE erstellt wird. Diese Tabelle ist in der Beispieldatenbank definiert:

   CREATE TABLE EMPLOYEE
       (EMPNO     CHAR(6)      NOT NULL PRIMARY KEY,
       FIRSTNME   VARCHAR(12)  NOT NULL,
       MIDINIT    CHAR(1)      NOT NULL WITH DEFAULT,
       LASTNAME   VARCHAR(15)  NOT NULL,
       WORKDEPT   CHAR(3),
       PHONENO    CHAR(4),
       PHOTO      BLOB(10M)    NOT NULL)
   IN RESOURCE

Beim Erstellen einer Tabelle können Sie angeben, daß die Spalten der Tabelle auf den Attributen eines strukturierten Typs basieren sollen. Eine Solche Tabelle wird als "typisierte Tabelle" bezeichnet.

Eine typisierte Tabelle kann so definiert werden, daß sie einige ihrer Spalten aus einer anderen typisierten Tabelle übernimmt. Eine solche Tabelle wird als "untergeordnete Tabelle" bezeichnet und die Tabelle, aus der sie Spalten übernimmt, als "übergeordnete Tabelle". Eine typisierte Tabelle mit allen untergeordneten Tabellen wird als "Tabellenhierarchie" bezeichnet. Die oberste Tabelle in der Tabellenhierarchie (zu der es keine übergeordnete Tabelle gibt) wird als "Stammtabelle" der Hierarchie bezeichnet.

Die folgenden Abschnitte gehen von diesem Beispiel aus, um einige andere Optionen zu behandeln, die bedacht werden sollten:

Sie können auch eine Tabelle erstellen, die auf Grundlage eines Abfrageergebnisses definiert ist. Diese Art von Tabelle wird eine Übersichtstabelle genannt. Weitere Informationen finden Sie in Erstellen einer Übersichtstabelle.

Überlegungen zu LOB-Spalten

Bevor Sie eine Tabelle erstellen, die Spalten mit großen Objekten (LOB-Spalten) enthält, müssen Sie folgende Entscheidungen treffen:

  1. Sollen Änderungen an LOB-Spalten protokolliert werden?

    Wenn Sie diese Änderungen nicht protokollieren wollen, müssen Sie die Protokollierung inaktivieren, indem Sie die Klausel NOT LOGGED bei der Erstellung der Tabelle angeben:

       CREATE TABLE EMPLOYEE
          (EMPNO     CHAR(6)     NOT NULL PRIMARY KEY,
           FIRSTNME   VARCHAR(12)  NOT NULL,
           MIDINIT   CHAR(1)     NOT NULL WITH DEFAULT,
           LASTNAME   VARCHAR(15)  NOT NULL,
           WORKDEPT   CHAR(3),
           PHONENO    CHAR(4),
           PHOTO     BLOB(10M)   NOT NULL  NOT LOGGED)
       IN RESOURCE
    

    Wenn die LOB-Spalte Daten mit einer Größe von über 1 GB enthält, muß die Protokollierung inaktiviert werden. (Als Faustregel gilt, daß LOB-Spalten mit einer Größe über 10 MB Größe meist nicht protokolliert werden sollten.) Wie bei anderen Optionen auch, die in einer Spaltendefinition angegeben werden, kann die Einstellung der Protokolloption nur geändert werden, indem die Tabelle neu erstellt wird.

    Auch wenn Sie angeben, daß die Änderungen nicht protokolliert werden sollen, werden LOB-Spalten auf bestimmte Art gespiegelt, damit Änderungen rückgängig gemacht werden können, wenn ein Systemfehler oder eine Anforderung durch eine Anwendung dies erforderlich macht. Dieses Spiegeln ist eine Wiederherstellungsmethode, bei der der aktuelle Inhalt der Speicherseiten nicht überschrieben wird. Das heißt, alte, nicht geänderte Seiten werden als "Spiegelkopien" zurückbehalten. Diese Kopien werden gelöscht, wenn sie zur Unterstützung der Zurücksetzung einer Transaktion nicht mehr benötigt werden.
    Anmerkung:Bei der Wiederherstellung einer Datenbank mit den Befehlen RESTORE und ROLLFORWARD werden LOB-Daten, die nicht protokolliert ("NOT LOGGED") wurden und die seit der letzten Sicherung geschrieben wurden, durch binäre Nullen ersetzt.

  2. Soll der für die LOB-Spalte erforderliche Speicherbereich minimiert werden?

    Sie können die LOB-Spalte so klein wie möglich halten, wenn Sie die Klausel COMPACT in der Anweisung CREATE TABLE verwenden. Beispiel:

       CREATE TABLE EMPLOYEE
          (EMPNO     CHAR(6)     NOT NULL PRIMARY KEY,
           FIRSTNME   VARCHAR(12)  NOT NULL,
           MIDINIT   CHAR(1)     NOT NULL WITH DEFAULT,
           LASTNAME   VARCHAR(15)  NOT NULL,
           WORKDEPT   CHAR(3),
           PHONENO    CHAR(4),
           PHOTO     BLOB(10M)   NOT NULL  NOT LOGGED  COMPACT)
       IN RESOURCE
    

    Wenn Daten an eine Tabelle mit einer kompakten LOB-Spalte (COMPACT) angehängt werden, kommt es zu Leistungseinbußen, besonders wenn dabei die Größe der LOB-Werte erhöht wird. (Dies wird durch erforderliche Speicheranpassungen verursacht.)

    Auf Plattformen wie OS/2, die die Zuordnung von Dateien mit freien Bereichen nicht unterstützen, und wo große Objekte (LOBs) in SMS-Tabellenbereichen untergebracht werden, sollten Sie die Klausel COMPACT verwenden. Die Zuordnung von Dateien mit freien Bereichen hängt mit der Art und Weise zusammen, wie ein Betriebssystem den physischen Plattenspeicher verwendet. Ein Betriebssystem, das die Zuordnung von Dateien mit freien Bereichen unterstützt, belegt im Vergleich zu Betriebssystemen, die die Zuordnung solcher Dateien nicht unterstützen, weniger physischen Speicherbereich zur Speicherung großer Objekte (LOBs). Die Option COMPACT ermöglicht noch größere "Einsparungen" im Hinblick auf den physischen Speicher, unabhängig davon, ob die Zuordnung von Dateien mit freien Bereichen unterstützt wird oder nicht. Da Sie durch die Verwendung der Klausel COMPACT gewisse "Einsparungen" an physischem Plattenspeicher erzielen können, sollten Sie in Betracht ziehen, die Klausel COMPACT zu verwenden, wenn Ihr Betriebssystem die Zuordnung von Dateien mit freien Bereichen nicht unterstützt.
    Anmerkung:Die DB2-Systemkataloge verwenden LOB-Spalten und belegen eventuell mehr Speicher als in früheren Versionen.

  3. Wünschen Sie eine Leistungssteigerung für LOB-Spalten, einschließlich jener LOB-Spalten in den DB2-Systemkatalogen?

    In den Katalogtabellen gibt es Spalten mit großen Objekten (LOB-Spalten). LOB-Daten werden nicht mit anderen Daten im Pufferpool behalten, sondern jedesmal, wenn sie benötigt werden, von der Platte gelesen. Das Lesen von der Platte verlangsamt die Leistung von DB2, wenn LOB-Spalten der Kataloge beteiligt sind. Da ein Dateisystem in der Regel über eigene Mechanismen zum Zwischenspeichern (Caching) von Daten verfügt, kann die Verwendung eines SMS-Tabellenbereichs oder eines DMS-Tabellenbereichs, der auf Dateibehältern basiert, die E/A-Operationen möglicherweise umgehen, wenn auf die LOB-Daten zuvor bereits zugegriffen wurde.

Definieren von Integritätsbedingungen

In diesem Abschnitt wird die Definition von Integritätsbedingungen behandelt:

Weitere Informationen zu Integritätsbedingungen finden Sie in Planen der Integritätsbedingungen und im Handbuch SQL Reference.

Definieren einer eindeutigen Integritätsbedingung

Eindeutige Integritätsbedingungen stellen sicher, daß jeder Wert im angegebenen Schlüssel eindeutig ist. Eine Tabelle kann mehrere Integritätsbedingungen für Eindeutigkeit haben, wobei maximal eine eindeutige Integritätsbedingung als Primärschlüssel definiert sein kann.

Eine eindeutige Integritätsbedingung wird mit der Klausel UNIQUE in der Anweisung CREATE TABLE bzw. ALTER TABLE definiert. Ein eindeutiger Schlüssel kann aus mehr als einer Spalte bestehen. In einer Tabelle ist mehr als eine eindeutige Integritätsbedingung zulässig. Eine eindeutige Integritätsbedingung kann jedoch nicht in einer untergeordneten Tabelle definiert werden.

Wenn die eindeutige Integritätsbedingung definiert ist, wird sie vom Datenbankmanager automatisch umgesetzt, wenn eine INSERT- oder UPDATE-Anweisung die Daten in der Tabelle ändert. Die eindeutige Integritätsbedingung wird mit Hilfe eines eindeutigen Index realisiert.

Wenn eine eindeutige Integritätsbedingung in einer Anweisung ALTER TABLE definiert wird und ein Index für dieselbe Gruppe von Spalten dieses eindeutigen Schlüssels existiert, wird dieser Index zum eindeutigen Index und wird von der Integritätsbedingung verwendet.

Sie können jede einzelne eindeutige Integritätsbedingung als Primärschlüssel verwenden. Der Primärschlüssel kann als übergeordneter Schlüssel in einer referentiellen Integritätsbedingung (zusammen mit anderen eindeutigen Integritätsbedingungen) verwendet werden. Es kann nur einen Primärschlüssel pro Tabelle geben. Ein Primärschlüssel wird mit der Klausel PRIMARY KEY in der Anweisung CREATE TABLE bzw. ALTER TABLE definiert. Der Primärschlüssel kann aus mehr als einer Spalte bestehen.

Für den Primärindex ist es zwingend erforderlich, daß der Primärschlüssel eindeutig ist. Wenn eine Tabelle mit einem Primärschlüssel erstellt wird, legt der Datenbankmanager einen Primärindex für diesen Schlüssel an.

Einige Hinweise zur Leistungsoptimierung für Indizes, die für eindeutige Integritätsbedingungen verwendet werden:

Definieren referentieller Integritätsbedingungen

Referentielle Integrität wird durch Hinzufügen referentieller Integritätsbedingungen zu Tabellen- und Spaltendefinitionen implementiert. Referentielle Integritätsbedingungen werden mit der Klausel FOREIGN KEY und der Klausel REFERENCES in der Anweisung CREATE TABLE oder ALTER TABLE definiert. Weitere Informationen zu den Auswirkungen einer referentiellen Integritätsbedingung auf typisierte Tabellen oder übergeordnete typisierte Tabellen enthält das Handbuch SQL Reference.

Die Definition von Fremdschlüsseln implementiert Integritätsbedingungen für die Werte innerhalb der Zeilen einer Tabelle oder zwischen den Zeilen zweier Tabellen. Der Datenbankmanager prüft die in einer Tabellendefinition angegebenen Integritätsbedingungen und verwaltet die Abhängigkeitsbeziehungen entsprechend. Das Ziel besteht darin, die Integrität zu erhalten, wenn ein Datenbankobjekt auf ein anderes verweist.

Zum Beispiel enthalten sowohl der Primärschlüssel als auch der Fremdschlüssel eine Spalte für die Abteilungsnummer. In der Tabelle EMPLOYEE heißt der Spaltenname WORKDEPT, während in der Tabelle DEPARTMENT der Name DEPTNO ist. Die Abhängigkeitsbeziehung zwischen diesen beiden Tabellen wird durch die folgenden Integritätsbedingungen definiert

Die SQL-Anweisung zur Definition der übergeordneten Tabelle DEPARTMENT sieht folgendermaßen aus:

      CREATE TABLE DEPARTMENT
      (DEPTNO    CHAR(3)     NOT NULL,
       DEPTNAME  VARCHAR(29) NOT NULL,
       MGRNO     CHAR(6),
       ADMRDEPT  CHAR(3)     NOT NULL,
       LOCATION  CHAR(16),
       PRIMARY KEY (DEPTNO))
   IN RESOURCE

Die SQL-Anweisung zur Definition der abhängigen Tabelle EMPLOYEE sieht folgendermaßen aus:

   CREATE TABLE EMPLOYEE
      (EMPNO     CHAR(6)     NOT NULL PRIMARY KEY,
       FIRSTNME   VARCHAR(12)  NOT NULL,
       LASTNAME   VARCHAR(15)  NOT NULL,
       WORKDEPT   CHAR(3),
       PHONENO    CHAR(4),
       PHOTO     BLOB(10m)   NOT NULL,
       FOREIGN KEY DEPT (WORKDEPT)
       REFERENCES DEPARTMENT ON DELETE NO ACTION)
   IN RESOURCE

Durch Angeben der Spalte DEPTNO als Primärschlüssel der Tabelle DEPARTMENT und der Spalte WORKDEPT als Fremdschüssel der Tabelle EMPLOYEE definieren Sie eine referentielle Integritätsbedingung für die Werte der Spalte WORKDEPT. Durch diese Integritätsbedingung wird die referentielle Integrität zwischen den Werten der beiden Tabellen implementiert. In vorliegenden Fall müssen alle Mitarbeiter (Employees), die der Tabelle EMPLOYEE hinzugefügt werden, eine Abteilungsnummer erhalten, die in der Tabelle DEPARTMENT enthalten ist.

Die Löschbedingung für die referentielle Integritätsbedingung in der Tabelle EMPLOYEE ist NO ACTION. Das heißt, daß eine Abteilung (Department) nicht aus der Tabelle DEPARTMENT gelöscht werden kann, wenn es Mitarbeiter in dieser Abteilung gibt.

Zum Hinzufügen einer referentiellen Integritätsbedingung kann nicht nur die in den Beispielen gezeigte Anweisung CREATE TABLE, sondern auch die Anweisung ALTER TABLE verwendet werden. Siehe Ändern von Struktur und Inhalt einer Tabelle.

Ein weiteres Beispiel: Es werden dieselben Tabellendefinitionen wie im vorigen Beispiel verwendet. Außerdem wird die Tabelle DEPARTMENT vor der Tabelle EMPLOYEE erstellt. Jede Abteilung hat einen Manager, und dieser Manager wird in der Tabelle EMPLOYEE aufgeführt. Die Spalte MGRNO der Tabelle DEPARTMENT stellt tatsächlich einen Fremdschlüssel der Tabelle EMPLOYEE dar. Aufgrund dieses referentiellen Zyklus führt diese Integritätsbedingung zu einem kleinen Problem. Sie könnten einen Fremdschlüssel später hinzufügen (siehe Hinzufügen von Primär- und Fremdschlüsseln). Sie könnten außerdem die Anweisung CREATE SCHEMA verwenden, um die Tabellen EMPLOYEE und DEPARTMENT gleichzeitig zu erstellen (siehe Beispiel im Handbuch SQL Reference).

Klausel FOREIGN KEY

Ein Fremdschlüssel verweist auf einen Primärschlüssel oder einen eindeutigen Schlüssel in derselben oder einer anderen Tabelle. Die Zuordnung eines Fremdschlüssels zeigt an, daß die referentielle Integrität gemäß der angegebenen referentiellen Integritätsbedingungen erhalten bleiben soll. Ein Fremdschlüssel wird mit der Klausel FOREIGN KEY in der Anweisung CREATE TABLE bzw. ALTER TABLE definiert.

Die Anzahl der Spalten im Fremdschlüssel muß mit der Anzahl der Spalten im entsprechenden Primärschlüssel oder eindeutigen Schlüssel (auch als übergeordneter Schlüssel bezeichnet) der übergeordneten Tabelle übereinstimmen. Darüber hinaus müssen sich entsprechende Teile der Schlüsselspaltendefinitionen dieselben Datentypen und Datenlängen haben. Dem Fremdschlüssel kann ein Integritätsbedingungsname zugeordnet werden. Wenn Sie keinen Namen zuordnen, wird der Name automatisch zugeordnet. Zur leichteren Handhabung wird empfohlen, einen Integritätsbedingungsnamen zuzuordnen und nicht den vom System generierten Namen zu verwenden.

Der Wert eines zusammengesetzten Fremdschlüssels stimmt mit dem Wert eines Primärschlüssels überein, wenn der Wert jeder Spalte des Fremdschlüssels gleich dem Wert der entsprechenden Spalte des Primärschlüssels ist. Ein Fremdschlüssel, der Nullwerte enthält, kann nicht mit den Werten des Primärschlüssels übereinstimmen, da per Definition ein Primärschlüssels keine Nullwerte enthalten darf. Ein Nullwert eines Fremdschlüssels ist immer gültig, ungeachtet der Werte seiner Nichtnullwertspalten.

Für die Definition von Fremdschlüsseln gelten die folgenden Regeln:

Klausel REFERENCES

Mit der Klausel REFERENCES werden die übergeordnete Tabelle in einer Abhängigkeitsbeziehung identifiziert und die nötigen Integritätsbedingungen definiert. Diese Klausel kann in einer Spaltendefinition oder als separate Klausel, die eine Klausel FOREIGN KEY begleitet, in einer Anweisung CREATE TABLE bzw. ALTER TABLE angegeben werden.

Wenn die Klausel REFERENCES als Spaltenintegritätsbedingung angegeben wird, wird eine implizite Spaltenliste aus dem bzw. den Spaltennamen, die aufgelistet werden, gebildet. Beachten Sie, daß mehrere Spalten getrennte Klauseln REFERENCES haben können und daß eine einzelne Spalte mehr als eine Klausel REFERENCES haben kann.

In die Klausel REFERENCES ist eine Löschbedingung eingeschlossen. Im gezeigten Beispiel wird die Löschbedingung ON DELETE NO ACTION verwendet, die angibt, daß keine Abteilung gelöscht werden kann, wenn ihr Mitarbeiter zugeordnet sind. Andere Löschbedingungen sind ON DELETE CASCADE, ON DELETE SET NULL, und ON DELETE RESTRICT. Siehe Regeln zur Anweisung DELETE.

Auswirkungen auf Dienstprogramme

Das Dienstprogramm LOAD inaktiviert die Prüfung der Integritätsbedingungen für auf sich selbst verweisende und abhängige Tabellen und setzt diese Tabellen in einen Status, der besagt, daß die Prüfung noch ansteht. Nach Beendigung des Dienstprogramms LOAD müssen Sie die Prüfung der Integritätsbedingungen für alle Tabellen, für die diese Prüfung inaktiviert wurde, wieder aktivieren. Wenn beispielsweise die Tabellen DEPARTMENT und EMPLOYEE die einzigen Tabellen sind, die in den Status "Überprüfung anstehend" gesetzt wurden, können Sie folgenden Befehl ausführen:

   SET INTEGRITY FOR DEPARTMENT, EMPLOYEE IMMEDIATE CHECKED

Das Dienstprogramm IMPORT wird auf folgende Weise durch die referentiellen Integritätsbedingungen beeinflußt:

Definieren von Prüfungen auf Integritätsbedingungen in Tabellen

Eine Prüfung auf Integritätsbedingung in einer Tabelle (Table Check Constraint) gibt eine Suchbedingung an, die für jede Zeile der Tabelle implementiert wird, für die die Prüfung definiert ist. Sie können eine Prüfung auf Integritätsbedingung in einer Tabelle einrichten, indem Sie eine Prüfdefinition der Tabelle zuordnen, wenn die Tabelle erstellt (CREATE TABLE) bzw. geändert (ALTER TABLE) wird. Diese Prüfbedingung wird automatisch aktiviert, wenn durch eine Anweisung INSERT oder UPDATE die Daten in der Tabelle geändert werden. Eine Prüfung auf Integritätsbedingung in einer Tabelle hat keine Auswirkung auf eine Anweisung DELETE oder SELECT. Eine Prüfung auf Integritätsbedingung kann einer typisierten Tabelle zugeordnet werden.

Ein Integritätsbedingungsname kann nicht derselbe sein wie ein anderer Integritätsbedingungsname innerhalb derselben Anweisung CREATE TABLE. Wenn Sie keinen Integritätsbedingungsnamen angeben, wird vom System ein eindeutiger Bezeichner aus 18 Zeichen für die Integritätsbedingung generiert.

Eine Prüfung auf Integritätsbedingung in einer Tabelle wird zur Implementierung der Regeln für die Datenintegrität verwendet, die nicht durch die Eindeutigkeit des Schlüssels oder einer referentiellen Integritätsbedingung abgedeckt sind. In einigen Fällen kann eine Prüfbedingung verwendet werden, um Wertebereiche zu überprüfen. Die folgende Prüfung auf Integritätsbedingung in der Anweisung CREATE TABLE stellt sicher, daß das Anfangsdatum für jede Tätigkeit nicht nach dem Enddatum für dieselbe Tätigkeit liegt:

   CREATE TABLE EMP_ACT
      (EMPNO        CHAR(6)      NOT NULL,
       PROJNO     CHAR(6)      NOT NULL,
       ACTNO      SMALLINT     NOT NULL,
       EMPTIME    DECIMAL(5,2),
       EMSTDATE   DATE,
       EMENDATE   DATE,
       CONSTRAINT ACTDATES CHECK(EMSTDATE <= EMENDATE) )
   IN RESOURCE

Zum Hinzufügen einer Prüfung auf Integritätsbedingung kann nicht nur die im Beispiel gezeigte Anweisung CREATE TABLE, sondern auch die Anweisung ALTER TABLE verwendet werden. Siehe Ändern von Struktur und Inhalt einer Tabelle.

Definieren einer generierten Spalte in einer neuen Tabelle

Eine generierte Spalte wird in einer Basistabelle definiert, bei der der gespeicherte Wert mit Hilfe eines Ausdrucks ermittelt wird, anstatt mit einer Einfüge- oder Aktualisierungsoperation angegeben zu werden. Beim Erstellen einer Tabelle, bei der bestimmte Ausdrücke und Prädikate ständig verwendet werden, können eine oder mehrere generierte Tabellen zu dieser Tabelle hinzugefügt werden. Durch die Verwendung einer generierten Spalte ergibt sich die Möglichkeit, bei der Durchführung von Abfragen in den Tabellendaten eine verbesserte Leistung zu erzielen.

Es gibt z. B. zwei Situationen, bei denen die Bewertung von Ausdrücken aufwendig sein kann, wenn die Leistung wichtig ist:

  1. Die Bewertung des Ausdrucks muß während einer Abfrage oft durchgeführt werden.
  2. Die Berechnung ist komplex.

Um die Leistung einer Abfrage zu verbessern, können Sie eine zusätzliche Spalte definieren, die die Resultate des Ausdrucks enthält. Beim Absetzen einer Abfrage mit demselben Ausdruck kann die generierte Spalte dann direkt verwendet werden. Andernfalls kann die Komponente zum erneuten Schreiben von Abfragen, die im Optimierungsprogramm implementiert ist, den Ausdruck gegen die generierte Spalte austauschen.

Es ist außerdem möglich, für eine generierte Spalte einen nicht eindeutigen Index zu erstellen.

Wenn bei Abfragen Daten von zwei oder mehr Tabellen verknüpft werden, ermöglicht das Hinzufügen einer generierten Spalte dem Optimierungsprogramm die Auswahl potentiell besserer Verknüpfungsstrategien.

Im folgenden ist ein Beispiel für das Definieren einer generierten Spalte für die Anweisung CREATE TABLE aufgeführt:

   CREATE TABLE t1 (c1 INT,
                    c2 DOUBLE,
                    c3 DOUBLE GENERATED ALWAYS AS (c1 + c2)
                    c4 GENERATED ALWAYS AS
                       (CASE WHEN c1 > c2 THEN 1 ELSE NULL END))

Nach dem Erstellen dieser Tabelle können mit Hilfe der generierten Spalten Indizes erstellt werden. Beispiel:

   CREATE INDEX i1 ON t1(c4)

Abfragen können die Vorteile generierter Spalten nutzen. Beispiel:

   SELECT COUNT(*) FROM t1 WHERE c1 > c2

Diese Anweisung kann folgendermaßen angegeben werden:

   SELECT COUNT(*) FROM t1 WHERE c4 IS NOT NULL

Zweites Beispiel:

   SELECT c1 + c2 FROM t1 WHERE (c1 + c2) * c1 > 100

Diese Anweisung kann folgendermaßen angegeben werden:

   SELECT c3 FROM t1 WHERE c3 * c1 > 100

Generierte Spalten können zur Verbesserung der Leistung von Abfragen eingesetzt werden. Aus diesem Grund werden generierte Spalten häufig nach dem Erstellen und Füllen einer Tabelle mit Werten zu dieser hinzugefügt. Weitere Informationen finden Sie in Erstellen und Auffüllen einer Tabelle.

Erstellen einer benutzerdefinierten temporären Tabelle

Mit der Anweisung DECLARE GLOBAL TEMPORARY TABLE werden temporäre Tabellen definiert. Die Anweisung wird innerhalb der Anwendung abgesetzt. Die benutzerdefinierte temporäre Tabelle bleibt nur so lange erhalten, bis die Anwendung die Verbindung zur Datenbank trennt.

Die Beschreibung dieser Tabelle wird im Systemkatalog nicht angezeigt, so daß sie von anderen Anwendungen nicht identifiziert und gemeinsam verwendet werden kann.

Wenn die Anwendung, die diese Tabelle verwendet, beendet wird oder die Verbindung zur Datenbank trennt, werden alle Daten in dieser Tabelle gelöscht und auch die Tabelle wird implizit gelöscht.

Im folgenden ist ein Beispiel aufgeführt, wie eine temporäre Tabelle definiert werden kann:

   DECLARE GLOBAL TEMPORARY TABLE gbl_temp
      LIKE empltabl
      ON COMMIT DELETE ROWS
      NOT LOGGED
      IN usr_tbsp

Diese Anweisung erstellt eine temporäre Benutzertabelle mit dem Namen gbl_temp. Die temporäre Benutzertabelle wurde mit Spalten definiert, die über exakt dieselben Namen und Beschreibungen verfügen wie die Spalten von empltabl. Die implizite Definition umfaßt nur den Spaltennamen, den Datentyp, Angaben zur Verwendung von Nullwerten sowie die Standardwertattribute für die Spalte. Alle anderen Spaltenattribute einschließlich der eindeutigen Integritätsbedingungen, Auslöser und Indizes werden nicht definiert. Bei der Ausführung einer COMMIT-Operation werden alle Daten in der Tabelle gelöscht, wenn für die Tabelle kein WITH HOLD-Cursor geöffnet wurde. Die an der temporären Benutzertabelle vorgenommenen Änderungen werden nicht protokolliert. Die temporäre Benutzertabelle wird im angegebenen temporären Benutzertabellenbereich gespeichert. Dieser Tabellenbereich muß vorhanden sein, da andernfalls die Deklaration der Tabelle fehlschlägt.

Zusätzliche Informationen zur Anweisung DECLARE GLOBAL TEMPORARY TABLE finden Sie im Handbuch SQL Reference.
Anmerkung:Eine benutzerdefinierte temporäre Tabelle bietet keine Unterstützung für die folgenden Elemente:
  • LOB-Spalten (oder Spalten eines anderen Typs, die ebenfalls auf LOB basieren)
  • Benutzerdefinierte Spalten
  • LONG VARCHAR-Spalten
  • DATALINK-Spalten

Definieren einer Identitätsspalte in einer neuen Tabelle

Eine Identitätsspalte ermöglicht DB2 das automatische Generieren eines garantiert eindeutigen, numerischen Wertes für jede Zeile, die zu der Tabelle hinzugefügt wird. Beim Erstellen einer Tabelle, bei der bekannt ist, daß jede zur Tabelle hinzugefügte Zeile eindeutig identifiziert werden muß, können Sie eine Identitätsspalte zur Tabelle hinzufügen.

Nach der Erstellung können Sie die Tabellenbeschreibung nicht mehr ändern und eine Identitätsspalte einfügen.

Identitätsspalten können mit der Klausel AS IDENTITY der Anweisung CREATE TABLE angegeben werden.

Im folgenden ist ein Beispiel für das Definieren einer Identitätsspalte für die Anweisung CREATE TABLE aufgeführt:

   CREATE TABLE table (col1 INT,
                       col2 DOUBLE,
                       col3 INT NOT NULL GENERATED ALWAYS AS IDENTITY
                                         (START WITH 100, INCREMENT BY 5))

In diesem Beispiel wurde die dritte Spalte als Identitätsspalte definiert. Sie können darüber hinaus den in der Spalte verwendeten Wert zum eindeutigen Identifizieren aller hinzugefügten Zeilen verwenden. Im vorliegenden Beispiel wird für die erste eingegebene Zeile der Wert "100" in der Spalte plaziert. Für jede nachfolgend zu der Tabelle hinzugefügte Zeile wird der zugehörige Wert um 5 erhöht.

Außerdem können Identitätsspalten für die Zuordnung von Bestellnummern, Personalnummern, Produktnummern oder Ereignisnummern verwendet werden. Die Werte für eine Identitätsspalte können unter DB2 mit ALWAYS oder BY DEFAULT generiert werden.

Eine mit GENERATED ALWAYS definierte Identitätsspalte ist garantiert eindeutig. Die verwendeten Werte werden immer mit DB2 generiert. Für Anwendungen ist die Angabe eines expliziten Wertes nicht zulässig. Eine mit GENERATED BY DEFAULT definierte Identitätsspalte ermöglicht Anwendungen die explizite Angabe eines Wertes für die Identitätsspalte. Wenn die Anwendung keinen Wert bereitstellt, wird ein entsprechender Wert von DB2 generiert. Da der Wert von der Anwendung gesteuert wird, kann seine Eindeutigkeit durch DB2 nicht garantiert werden. Die Klausel GENERATED BY DEFAULT sollte für die Datenweitergabe eingesetzt werden, wenn der Inhalt einer vorhandenen Tabelle kopiert werden soll. Andere Einsatzbereiche sind das Entladen und das erneute Laden einer Tabelle.
Anmerkung:Identitätsspalten werden momentan in Umgebungen mit partitionierten Datenbanken nicht unterstützt.

Zusätzliche Informationen zum Definieren einer Identitätsspalte in einer neuen Tabelle finden Sie im Handbuch SQL Reference.

Erstellen einer typisierten Tabelle

Sie können eine typisierte Tabelle unter Verwendung einer Variante der Anweisung CREATE TABLE erstellen. Umfassende Informationen zu typisierten Tabellen finden Sie im Handbuch Application Development Guide.

Auffüllen einer typisierten Tabelle

Nach dem Erstellen der strukturierten Typen können Sie eine typisierte Tabelle mit Daten füllen. Anschließend können Sie die entsprechenden Tabellen und untergeordneten Tabellen erstellen. Umfassende Informationen zu typisierten Tabellen finden Sie im Handbuch Application Development Guide.

Hierarchietabelle

Eine Hierarchietabelle ist eine Tabelle, die der Implementierung einer Hierarchie typisierter Tabellen zugeordnet ist. Sie wird zum gleichen Zeitpunkt erstellt wie die Stammtabelle der Hierarchie. Umfassende Informationen zu Hierarchietabellen finden Sie im Handbuch Application Development Guide.

Erstellen einer Tabelle in mehreren Tabellenbereichen

Tabellendaten können im selben Tabellenbereich wie der Tabellenindex und Daten in Spalten für große Objekte (LOBs) gespeichert werden, die der Tabelle zugeordnet sind. Sie können den Index und die Daten in Spalten für große Objekte (LOBs) auch in separaten Tabellenbereichen getrennt von dem Tabellenbereich für die restlichen Tabellendaten speichern. Alle Tabellenbereiche müssen vor der Ausführung der Anweisung CREATE TABLE vorhanden sein. Die Trennung der Tabellenkomponenten ist nur bei DMS-Tabellenbereichen möglich.

Gehen Sie wie folgt vor, um eine Tabelle mit der Steuerzentrale in mehreren Tabellenbereichen zu erstellen:
  1. Erweitern Sie die Sicht der Objektbaumstruktur so lange, bis der Ordner Tabellen angezeigt wird.
  2. Klicken Sie mit der rechten Maustaste auf dem Ordner Tabellen und wählen Sie dann im Kontextmenü Erstellen --> Tabellen mit Assistent aus.
  3. Geben Sie den Tabellennamen ein und klicken Sie dann auf Weiter.
  4. Wählen Sie die gewünschten Spalten für Ihre Tabelle aus.
  5. Klicken Sie auf der Seite Tabellenbereich auf Separaten Indexbereich verwenden und Separaten LOB-Bereich verwenden. Geben Sie die erforderlichen Informationen an und klicken Sie dann auf Fertigstellen.

Geben Sie in der Befehlszeile folgendes ein, um eine Tabelle in mehreren Tabellenbereichen zu erstellen:

   CREATE TABLE <name>
      (<spaltenname>  <datentyp>  <nullattribut>)
       IN <tabellenbereichsname>
       INDEX IN <indexbereichsname>
       LONG  IN <lob_bereichsname>

Das folgende Beispiel zeigt, wie die Tabelle EMP_PHOTO erstellt werden könnte, um die verschiedenen Teile der Tabelle in verschiedenen Tabellenbereichen zu speichern:

   CREATE TABLE EMP_PHOTO
      (EMPNO        CHAR(6)      NOT NULL,
       PHOTO_FORMAT VARCHAR(10)  NOT NULL,
       PICTURE      BLOB(100K) )
   IN RESOURCE
   INDEX IN RESOURCE_INDEXES
   LONG  IN RESOURCE_PHOTO

In diesem Beispiel werden die Daten der Tabelle EMP_PHOTO folgendermaßen gespeichert:

Der Abschnitt Überlegungen zum Tabellenbereichsentwurf enthält zusätzliche Überlegungen zur Verwendung mehrerer DMS-Tabellenbereiche für eine Tabelle.

Weitere Informationen finden Sie im Handbuch SQL Reference.

Erstellen einer Tabelle in einer partitionierten Datenbank

Bevor Sie eine Tabelle erstellen, die physisch geteilt oder partitioniert wird, müssen Sie folgende Punkte beachten:

Es gibt eine zusätzliche Option bei der Erstellung einer Tabelle in einer partitionierten Datenbankumgebung: den Partitionierungsschlüssel. Ein Partitionierungsschlüssel ist ein Schlüssel, der Teil der Definition einer Tabelle ist. Durch ihn wird die Partition bestimmt, in der die jeweilige Datenzeile gespeichert wird.

Die Auswahl eines geeigneten Partitionierungsschlüssels ist von großer Bedeutung, da der Schlüssel später nicht mehr geändert werden kann. Darüber hinaus müssen alle eindeutigen Indizes (und infolgedessen eindeutige Schlüssel bzw. Primärschlüssel) als Obermenge des Partitionierungsschlüssels definiert werden. Das heißt, wenn ein Partitionierungsschlüssel definiert wird, müssen eindeutige Schlüssel und Primärschlüssel alle die Spalten enthalten, die der Partitionierungsschlüssel enthält (sie können mehr Spalten haben).

Wenn Sie keinen Partitionierungsschlüssel explizit angeben, werden die folgenden Standardwerte verwendet. Stellen Sie sicher, daß der Standardpartitionierungsschlüssel geeignet ist.

Es folgt ein Beispiel:

      CREATE TABLE MIXREC (MIX_CNTL INTEGER NOT NULL,
                        MIX_DESC CHAR(20) NOT NULL,
                        MIX_CHR  CHAR(9) NOT NULL,
                        MIX_INT INTEGER NOT NULL,
                        MIX_INTS SMALLINT NOT NULL,
                        MIX_DEC DECIMAL NOT NULL,
                        MIX_FLT FLOAT NOT NULL,
                        MIX_DATE DATE NOT NULL,
                        MIX_TIME TIME NOT NULL,
                        MIX_TMSTMP TIMESTAMP NOT NULL)
                        IN MIXTS12
                        PARTITIONING KEY (MIX_INT) USING HASHING

In diesem Beispiel ist der Tabellenbereich MIXTS12 und der Partitionierungsschlüssel MIX_INT. Wenn der Partitionierungsschlüssel nicht explizit angegeben würde, würde die Spalte MIX_CNTL verwendet. (Wenn kein Primärschlüssel angegeben und kein Partitionierungsschlüssel definiert wird, wird die erste Spalte in der Liste, die keine Langfelddaten (LONG) enthält, als Partitionierungsschlüssel verwendet.)

Eine Zeile einer Tabelle und sämtliche Informationen zu dieser Zeile werden immer in derselben Datenbankpartition gespeichert.

Die Größenbegrenzung für eine Partition einer Tabelle ist 64 GB oder der verfügbare Plattenspeicherplatz, je nachdem, welcher Wert kleiner ist. (Hierbei wird von einer 4-KB-Seitengröße für den Tabellenbereich ausgegangen.) Die Größe der Tabelle kann auf bis zu 64 GB (oder dem verfügbaren Plattenspeicherplatz) multipliziert mit der Anzahl der Datenbankpartitionen anwachsen. Wenn die Seitengröße für den Tabellenbereich 8 KB beträgt, kann die Größe der Tabelle auf bis zu 128 GB (oder dem verfügbaren Plattenspeicherplatz) multipliziert mit der Anzahl der Datenbankpartitionen anwachsen. Wenn die Seitengröße für den Tabellenbereich 16 KB beträgt, kann die Größe der Tabelle auf bis zu 256 GB (oder den verfügbaren Plattenspeicherplatz) multipliziert mit der Anzahl der Datenbankpartitionen anwachsen. Wenn die Seitengröße für den Tabellenbereich 32 KB beträgt, kann die Größe der Tabelle auf bis zu 512 GB (oder den verfügbaren Plattenspeicherplatz) multipliziert mit der Anzahl der Datenbankpartitionen anwachsen.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]