Chapter 1. Introducing DB2 UDB for iSeries 5
1.2.1 DB2 UDB for iSeries basics
As previously mentioned, the major distinguishing characteristic of the iSeries server
database manager is that it is part of the operating system. In practice, this means that the
large majority of your iSeries server data is stored in the relational database. Although the
iSeries server also implements other file systems in its design, the relational database on the
iSeries server is the most commonly used by the customers. Your relational data is stored in
the database, plus typical non-relational information, such as the source of your application
programs.
Physical files and tables
Data on the iSeries server is stored in objects called physical files. Physical files consist of a
set of
records with a predefined layout. Defining the record layout means that you define the
data structure of the physical file in terms of the length and the type of
data fields that
participate in that particular layout.
These definitions can be made through the native data definition language of DB2 UDB for
iSeries, called
Data Description Specifications (DDS). If you are familiar with other relational
database platforms, you are aware that the most common way to define the structure of a
relational database is by using the data definition statements provided by the
Structured
Query Language
(SQL). This is also possible on the iSeries server. The SQL terminology can
be mapped to the native DB2 UDB for iSeries terminology for relational objects. An
SQL table
is equivalent to a DDS defined physical file. We use both terms interchangeably in this book.
Similarly, table
rows equate to physical file records for DB2 UDB for iSeries, and SQL
columns are a synonym for record fields.
Logical files, SQL views, and SQL indexes
By using DDS, you can define logical files on your physical files or tables. Logical files
provide a different view of the physical data, allowing columns subsetting, record selection,
joining multiple database files, and so on. They can also provide physical files with an access
path when you define a
keyed logical file. Access paths can be used by application programs
to access records directly by key or for ensuring uniqueness.
On the SQL side, there are similar concepts. An
SQL view is almost equivalent to a native
logical file. The selection criteria that you can apply in an SQL view is much more
sophisticated than in a native logical file. An
SQL index provides a keyed access path for the
physical data exactly the same way as a keyed logical file does. Still, SQL views and indexes
are treated differently from native logical files by DB2 UDB for iSeries, and they cannot be
considered to exactly coincide.
“Database file” refers to any DB2 UDB for iSeries file, such as a logical or physical file, an
SQL table, or view. Any database files can be used by applications for accessing DB2 UDB
for iSeries data.
DB2 UDB for iSeries in a distributed environment
It is becoming more and more common for companies and businesses to organize their
computing environment in a distributed way. The need to access remote data is constantly
growing. DB2 UDB for iSeries provides several options for operating with remote platforms,
both homogeneous and heterogeneous.
The Distributed Data Management (DDM) architecture is the basis for distributed file access.
You can create a DDM file on your iSeries server and have it direct your data access requests
to a remote database file. This remote file can be another DB2 UDB for iSeries database file
or a Customer Information Control System (CICS) managed data file residing on a host
platform. Only native data access is allowed for DDM files.
我的内容管理
展开
