DATABASE OBJECT

By
Team Teaching
Agenda

■ Schema
■ Database Objects
■ Alias
■ Table Types
– Regular Table
– Temporary Table
– Materialized Query Table (MQT)
– View
– Historical Table
■ Indexes
■ Sequences
DB2 Object Hierarchy
Schemas

■ A schema is a collection of named objects;

– it provides a way to group those objects logically.
– A schema is also a name qualifier;
– it provides a way to use the same natural name for
several objects, and to prevent ambiguous references
to those objects.
– For example, the schema names 'INTERNAL' and
'EXTERNAL' make it easy to distinguish two different
SALES tables (INTERNAL.SALES, EXTERNAL.SALES).
■ Schemas also enable multiple applications to store data in
a single database without encountering namespace
collisions.
Schemas, Cont’d…

■ A schema can contain tables, views, nicknames,

triggers, functions, packages, and other objects. A
schema is itself a database object.
■ It is explicitly created using the CREATE SCHEMA
statement, with the current user or a specified
authorization ID recorded as the schema owner.
■ It can also be implicitly created when another
object is created, if the user has IMPLICIT_SCHEMA
authority.
Schemas, Cont’d…

■ There are some restrictions and recommendations that you must be aware
of when naming schemas.
– User-defined types (UDTs) cannot have schema names longer than the
schema length listed in SQL and XML limits.
– The following schema names are reserved words and must not be used:
SYSCAT, SYSFUN, SYSIBM, SYSSTAT, SYSPROC.
– To avoid potential problems upgrading databases in the future, do not
use schema names that begin with SYS. The database manager will not
allow you to create modules, procedures, triggers, user-defined types
or user-defined functions using a schema name beginning with SYS.
– It is recommended that you not use SESSION as a schema name.
Declared temporary tables must be qualified by SESSION. It is therefore
possible to have an application declare a temporary table with a name
identical to that of a persistent table, in which case the application
logic can become overly complicated. Avoid the use of the schema
SESSION, except when dealing with declared temporary tables.
CREAT SCHEMA
STATEMENT
■ CREATE SCHEMA NAMA_SCHEMA
■ CONTOH :
– CREATE SCHEMA AKADEMIK
Set current schema

connect to musicdb user Keith;

select * from employee;
• Will select from KEITH.EMPLOYEE
set current schema = 'PAYROLL‘;
select * from employee;
• Will select from PAYROLL.EMPLOYEE
Aliases

■ An alias is an alternative name for an object such

as a module, table or another alias.
– It can be used to reference an object wherever
that object can be referenced directly.
■ An alias cannot be used in all contexts;
■ for example, it cannot be used in the check
condition of a check constraint. An alias cannot
reference a declared temporary table but it can
reference a created temporary table.
Aliases, Cont’d…

■ To create an alias using the command line, enter:

– CREATE ALIAS alias_name FOR table_name
■ The following SQL statement creates an alias WORKERS for the
EMPLOYEE table:
– CREATE ALIAS WORKERS FOR EMPLOYEE
■ The alias is replaced at statement compilation time by the table or view
name.
■ If the alias or alias chain cannot be resolved to a table or view name, an
error results.
■ For example, if WORKERS is an alias for EMPLOYEE, then at compilation
time:
– SELECT * FROM WORKERS
■ Becomes in effect
– SELECT * FROM EMPLOYEE
Tables

■ Tables are logical structures maintained by the

database manager.
■ Tables are made up of columns and rows.
■ At the intersection of every column and row is a
specific data item called a value.
■ A column is a set of values of the same type or one
of its subtypes.
■ A row is a sequence of values arranged so that the
nth value is a value of the nth column of the table.
Types of tables

■ Base tables
– These types of tables hold persistent data. There are
different kinds of base tables, including
■ Regular tables
– Regular tables with indexes are the "general purpose"
table choice.
■ Multidimensional clustering (MDC) tables (dwh)
■ Range-clustered tables (RCT) (dwh)
■ Partitioned tables (dwh)
■ Temporary tables
■ Materialized query tables
■ View
■ Hisotry Table
CREATE REGULAR TABLE

connect to musicdb;
create table artists
(artno smallint not null,
name varchar(50) with default 'abc',
classification char(1) not null,
bio clob(100K) logged,
picture blob( 10M) not logged compact)
in dms01
index in dms02
long in dms03;
Data types
Large Objects

■ Store large character strings, large binary strings,

or files
Application
Temporary Tables
■ Applications can utilize global temporary tables:
 Global temporary tables are stored in User temporary table
spaces
 The associated data is deleted when the application connection
ends
 Each connection accesses a private copy of the table, so it only
sees data put into the table by that one connection
 Normal table locking is not needed for global temporary tables
since the data is always limited to a single connection
 Type of Temporary Tables :
 Declared Global Temporary table:
 Created Global Temporary table:
Declared Global
Temporary table
■ These are defined during application execution
using the DECLARE GLOBAL TEMPORARY TABLE
statement
■ No DB2 Catalog information is required
■ The schema for a declared global temporary table
is always ‘SESSION’
Example of a
Declared Temporary
Table
 A System Administrator creates the user temporary table space
CREATE USER TEMPORARY TABLESPACE "USR_TEMP_TS"
PAGESIZE 4 K MANAGED BY AUTOMATIC STORAGE
BUFFERPOOL IBMDEFAULTBP ;
 The application uses SQL statements to declare and access the table
DECLARE GLOBAL TEMPORARY TABLE T1
LIKE REAL_T1
ON COMMIT DELETE ROWS
NOT LOGGED
IN USR_TEMP_TS;

INSERT INTO SESSION.T1

SELECT * FROM REAL_T1 WHERE DEPTNO=:mydept;
 /* do other work on T1 */
 /* when connection ends, table is automatically dropped */
Created Global
Temporary table
■ These are defined using a CREATE GLOBAL
TEMPORARY TABLE statement with a user selected
schema
■ The table and any associated indexes can be
created before an application connection starts, but
only the catalog definition exists
■ The catalog definition is used when the application
references the table
■ Each application connection still works only with
the data it stores in the table
Example of a Created
Temporary Table
■ A System Administrator creates the user temporary table space and defines a global
temporary table and indexes
CREATE USER TEMPORARY TABLESPACE "USR_TEMP_TS2"
PAGESIZE 4 K MANAGED BY AUTOMATIC STORAGE ;

CREATE GLOBAL TEMPORARY TABLE APP1.DEPARTMENT

LIKE PROD.DEPARTMENT
ON COMMIT DELETE ROWS
NOT LOGGED IN USR_TEMP_TS2;

CREATE INDEX APP1.DEPTIX1 ON APP1.DEPARTMENT (DEPTNO);

■ The application uses SQL statements to reference the temporary table; no DECLARE is
needed
INSERT INTO APP1.DEPARTMENT
SELECT * FROM PROD.DEPARTMENT WHERE DEPTNO=:mydept;
SELECT * FROM APP1.DEPARTMENT WHERE LASTNAME = ‘STOPFER’
VIEWS

■ Virtual table derived from other tables or views

■ Populated when invoked, based on a SELECT
statement
■ Some views can be updatable, others are read-
only
Historycal Table &
Time Traveling Query
■ Use temporal tables associated with Time Travel Query to
– assign time-based state information to your data.
– Data in tables that do not use temporal support
represents the present
– Data in temporal tables is valid for a period defined by
the database system, customer applications, or both
■ System-period temporal tables
– DB2 can automatically store the history of a table
– The history table contains deleted rows or the original
values of rows that have been updated so you can
query the past state of your data
How to Define a System-
Period Temporal Table
Query using a
System-Period
Temporal Table
Materialized Query
Tables (MQTs)
 Materialized query tables (MQTs) are tables whose definition is based on
the result of a query.
 The data consists of precomputed results from the tables that you specify
in the materialized query table definition.
 Materialized query tables (MQTs) are a powerful way to improve response
time for complex queries.
 This is especially true for queries that might require one or more of the
following operations:
 Aggregate data over one or more dimensions
 Joins and aggregate data over a group of tables
 Data from a commonly accessed subset of data; that is, from a "hot"
horizontal or vertical database partition
 Re-partitioned data from a table, or part of a table, in a partitioned
database environment
MQTs are classified by how
their data is maintained.
■ The following types are available:
– System-maintained MQTs (MAINTAINED BY
SYSTEM)
– User-maintained MQTs (MAINTAINED BY USER)
– Shadow tables (MAINTAINED BY REPLICATION)
– Federated_tool
-maintained MQTs or cache tables (MAINTAINED
BY FEDERATED_TOOL)
Creating a materialized
query table (MAINTAINED BY
SYTEM)
CREATE TABLE SATRIO.MQT_REKAP_TOTAL_EMP ( WORKDEPT, TOTAL_EMP )
AS
(
SELECT WORKDEPT, COUNT(EMPNO) TOTAL_EMP
FROM SATRIO.EMPLOYEE
GROUP BY WORKDEPT )
DATA INITIALLY DEFERRED
REFRESH DEFERRED
MAINTAINED BY SYSTEM
IN USERSPACE1
INDEX IN INDEXSPACE1;

SET INTEGRITY FOR SATRIO.MQT_REKAP_TOTAL_EMP IMMEDIATE CHECKED FULL ACCESS;

Indexes

■ Ordered set of pointers that refer to rows in a

base table.
■ They are based upon one or more columns
but stored as a separate entity.
Indexes

■ Good for performance and to guarantee

uniqueness
■ Index Characteristics:
– ascending or descending
– unique or non-unique
– compound
– cluster
– bi-directional (default behavior)
■ Examples:
create unique index artno_ix on artists (artno)
Sequence objects

■ Generates a unique numeric value

■ Used at the database level, independent of tables
■ Example:
CREATE SEQUENCE myseq
START WITH 1
INCREMENT BY 1
CACHE 5

INSERT INTO t1 VALUES (nextval for myseq, ...)

SELECT prevval for myseq FROM

sysibm.sysdummy1
Partitioned tables

■ Partitioned tables use a data organization scheme

in which table data is divided across multiple
storage objects, called data partitions or ranges,
according to values in one or more table
partitioning key columns of the table.
■ A data partition or range is part of a table,
containing a subset of rows of a table, and stored
separately from other sets of rows
Partitioned tables,
Cont’d…
■ Data from a given table is partitioned into multiple data
partitions or ranges based on the specifications provided in
the PARTITION BY clause of the CREATE TABLE statement.
These data partitions or ranges can be in different table
spaces, in the same table space, or a combination of both. If
a table is created using the PARTITION BY clause, the table
is partitioned.
■ All of the table spaces specified must have the same page
size, extent size, storage mechanism (DMS or SMS), and
type (REGULAR or LARGE), and all of the table spaces must
be in the same database partition group
■ You can create a partitioned table with a maximum of
32,767 data partitions
Example Table
partitioning
■ The following example creates a table named
CUSTOMER, where rows with l_shipdate >=
'01/01/2006' and l_shipdate <= '03/31/2006' are
stored in table space TS1, rows with l_shipdate >=
'04/01/2006' and l_shipdate <= '06/30/2006' are
stored in table space TS2, and so on.
Comparassion : Non Partitioned
Table vs Partitioned Table

■ Non Partitioned Table ■ Partitioned Table

Benefits of table
partitioning
■ If any of the following circumstances apply to you and
your organization, consider the numerous benefits of
table partitioning:
– You have a data warehouse that would benefit
from easier roll-in and roll-out of table data.
– You have a data warehouse that includes large
tables.
– You want to use hierarchical storage
management (HSM) solutions more effectively.
– Improved manageability
– Increased query performance
Table partitioning
keys
■ A table partitioning key is an ordered set of one or more columns in a
table. The values in the table partitioning key columns are used to
determine in which data partition each table row belongs.
■ To define the table partitioning key on a table use the CREATE TABLE
statement with the PARTITION BY clause.
■ Choosing an effective table partitioning key column is essential to taking
full advantage of the benefits of table partitioning. The following
guidelines can help you to choose the most effective table partitioning
key columns for your partitioned table.
– Define range granularity to match data roll-out. It is most common to
use week, month, or quarter.
– Define ranges to match the data roll-in size. It is most common to
partition data on a date or time column.
– Partition on a column that provides advantages in partition
elimination.
Supported data types
Unsupported data
types
•Data Type Column 1 •Data Type Column 2
•User defined types
•DBCLOB
(structured)
•LONG VARCHAR •LONG VARGRAPHIC
•LONG VARCHAR FOR
•REF
BIT DATA
•Varying length string for
•BLOB
C
•Varying length string for
•BINARY LARGE OBJECT
Pascal
•CLOB •XML
•CHARACTER LARGE
OBJECT
Example Table partitioning
Without “EVERY”
■ If you choose to automatically generate data
partitions using the EVERY clause of the CREATE
TABLE statement, only one column can be used as
the table partitioning key.
■ If you choose to manually generate data partitions
by specifying each range in the PARTITION BY
clause of the CREATE TABLE statement, multiple
columns can be used as the table partitioning key.
Creating partitioned
tables
■ To create a partitioned table from the command line, issue the
CREATE TABLE statement:

■ For example, the following statement creates a table where rows

with a ≥ 1 and a ≤ 20 are in PART0 (the first data partition), rows
with 21 ≤ a ≤ 40 are in PART1 (the second data partition), up to
81 ≤ a ≤ 100 are in PART4 (the last data partition).
Placement of the data,
index and long data of a
data partition
■ By its very nature, creating a partitioned table allows you to place the
various parts of the table and the associated table objects in specific
table spaces.
■ When creating a table you can specify in which table space the entire
table data and associated table objects will be placed. Or, you can place
the table's index, long or large data, or table partitions in specific table
spaces. All of the table spaces must be in the same database partition
group.
■ The CREATE TABLE statement has the following clauses which
demonstrate this ability to place the table data and associated table
objects within specific table spaces:
Placement of the data,
index and long data of a
data partition, Sample….
Materialized query
tables (MQTs)