DB2 Handout v1.0

Handout: DB2

Version: DB2/Handout/0308/1.0 Date: 20-03-08

Cognizant 500 Glen Pointe Center West Teaneck, NJ 07666 Ph: 201-801-0233 www.cognizant.com

Handout: DB2

TABLE OF CONTENTS Introduction .................................................................................................................................11  About this Module .......................................................................................................................11  Target Audience .........................................................................................................................11  Module Objectives ......................................................................................................................11  Pre-requisite ...............................................................................................................................11  Session 02: Introduction to DB2 Objects...................................................................................12  Learning Objectives ....................................................................................................................12  Database ....................................................................................................................................12  DBMS .........................................................................................................................................12  Database Model..........................................................................................................................12  RDBMS .......................................................................................................................................13  DB2 .............................................................................................................................................13  Storage Group ............................................................................................................................13  Database in detail .......................................................................................................................14  Table Space................................................................................................................................14  Index Space ................................................................................................................................15  Table ...........................................................................................................................................15  Column .......................................................................................................................................15  Row .............................................................................................................................................15  Table Terminology ......................................................................................................................16  Types of Table ............................................................................................................................16  Index ...........................................................................................................................................16  View ............................................................................................................................................17  Synonym .....................................................................................................................................19  Alias ............................................................................................................................................19  Physical Storage of Data ............................................................................................................20  Hierarchy of DB2 Objects ...........................................................................................................20  Buffer Pool ..................................................................................................................................21  Summary ....................................................................................................................................21  Test Your Understanding............................................................................................................22  Session 03: Database Design .....................................................................................................23  Learning Objectives ....................................................................................................................23  Why Should You Be Concerned with Database Design? ..........................................................23 

Page 2 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Activities involved in Database Design .......................................................................................23  Logical Database Design............................................................................................................24  Physical database design ...........................................................................................................36  Implementing and Altering Database Design .............................................................................37  Advantage of DB2 over VSAM ...................................................................................................37  Summary ....................................................................................................................................38  Test Your Understanding............................................................................................................38  Exercises ....................................................................................................................................39  Session 07: Data Integrity............................................................................................................40  Learning Objectives ....................................................................................................................40  Introduction to Data Integrity ......................................................................................................40  Entity Integrity .............................................................................................................................40  Referential Integrity ....................................................................................................................41  Rules ensuring RI: ......................................................................................................................41  Domain Integrity..........................................................................................................................42  Summary ....................................................................................................................................45  Test Your Understanding............................................................................................................46  Session 08: Interaction with DB2 ................................................................................................47  Learning Objectives ....................................................................................................................47  Interaction with DB2: Overview ..................................................................................................47  DB2I ............................................................................................................................................48  SPUFI .........................................................................................................................................49  QMF ............................................................................................................................................53  Summary ....................................................................................................................................58  Test Your Understanding............................................................................................................59  Session 09: SQL ...........................................................................................................................60  Learning Objectives ....................................................................................................................60  SQL: Overview............................................................................................................................60  DDL .............................................................................................................................................61  DDL – Create Storage Group .....................................................................................................61  DDL – Alter Storage Group ........................................................................................................61  Try It Out .....................................................................................................................................62  DDL – Create Database .............................................................................................................62  Try It Out .....................................................................................................................................63  DDL – Alter Database .................................................................................................................63  DDL – Create Tablespace ..........................................................................................................63 

Page 3 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Try It Out .....................................................................................................................................66  DDL – Alter Tablespace .............................................................................................................67  Summary ....................................................................................................................................68  Test Your Understanding............................................................................................................68  Session 10: SQL ...........................................................................................................................69  Learning Objectives ....................................................................................................................69  DDL – Create Table ....................................................................................................................69  Try It Out .....................................................................................................................................71  Try It Out .....................................................................................................................................72  Try It Out .....................................................................................................................................73  DDL – Alter Table .......................................................................................................................73  Try It Out .....................................................................................................................................74  DDL – Create Index ....................................................................................................................74  DDL – Alter Index .......................................................................................................................78  Try It Out .....................................................................................................................................79  DDL – Create View .....................................................................................................................80  DDL – Alter View ........................................................................................................................80  DDL – Create Alias .....................................................................................................................80  DDL – Create Synonym ..............................................................................................................80  DDL – DROP ..............................................................................................................................81  Summary ....................................................................................................................................81  Test Your Understanding............................................................................................................82  Exercises ....................................................................................................................................82  Session 11: SQL ...........................................................................................................................83  Learning Objectives ....................................................................................................................83  DML – Insert ...............................................................................................................................83  DML – Update.............................................................................................................................84  DML – Delete ..............................................................................................................................84  DML – Simple Retrieval ..............................................................................................................85  DML – Retrieving Multiple Columns ...........................................................................................85  DML – Retrieving All Columns....................................................................................................85  DML – Sorting Retrieved data ....................................................................................................85  DML – Sorting by Multiple Columns ...........................................................................................86  DML – Sorting by Column Position.............................................................................................86  DML – Specifying Sort Direction.................................................................................................86  DML – Filtering Data ...................................................................................................................86  DML – WHERE Clause Operators .............................................................................................87 

Page 4 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 DML – Advanced Filtering ..........................................................................................................88  DML – Wildcard Filtering ............................................................................................................89  DML – Removing Duplicates ......................................................................................................90  DML – Concatenating Fields ......................................................................................................90  DML – Using Aliases ..................................................................................................................90  DML – Performing Mathematical Calculations ...........................................................................91  DML – Functions.........................................................................................................................91  DML – Aggregate Functions .......................................................................................................91  DML – Text Functions ................................................................................................................92  DML – Date and Time Manipulation Functions ..........................................................................92  DML – Numeric Functions ..........................................................................................................93  Summary ....................................................................................................................................93  Test Your Understanding............................................................................................................94  Exercises ....................................................................................................................................94  Session 12: SQL ...........................................................................................................................96  Learning Objectives ....................................................................................................................96  DML – Grouping Data .................................................................................................................96  DML – Filtering Groups ..............................................................................................................97  DML – Grouping and Sorting ......................................................................................................97  DML – Subquery .........................................................................................................................97  DML – Join................................................................................................................................100  DML – Union .............................................................................................................................102  DCL ...........................................................................................................................................103  DCL - GRANT ...........................................................................................................................103  DCL - REVOKE ........................................................................................................................103  Summary ..................................................................................................................................104  Test Your Understanding..........................................................................................................104  Exercises ..................................................................................................................................104  Session 21: Introduction to Simple COBOL DB2 Application Program ...............................106  Learning Objectives ..................................................................................................................106  Embedded SQL ........................................................................................................................106  DCLGEN ...................................................................................................................................106  Host Variables ..........................................................................................................................111  SQLCA......................................................................................................................................112  SQLCODE ................................................................................................................................113  Try It Out ...................................................................................................................................113  Summary ..................................................................................................................................115 

Page 5 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Test Your Understanding..........................................................................................................115  Exercises ..................................................................................................................................115  Session 26: Program Preparation and Execution ...................................................................116  Learning Objectives ..................................................................................................................116  Steps involved in Program Preparation ....................................................................................116  Need for Precompilation ...........................................................................................................116  Tasks of Precompiler ................................................................................................................116  Bind ...........................................................................................................................................118  Plan ...........................................................................................................................................119  Need of Package ......................................................................................................................119  Package ....................................................................................................................................120  Understanding Plan and Package more clearly .......................................................................120  Version......................................................................................................................................120  Advantage of Version ...............................................................................................................120  Advantages of Package............................................................................................................120  Collection ..................................................................................................................................121  Advantages of Collection ..........................................................................................................121  Packages and Plans Storage ...................................................................................................125  Compile.....................................................................................................................................125  Link Edit ....................................................................................................................................126  Execution ..................................................................................................................................127  Try It Out ...................................................................................................................................128  Summary ..................................................................................................................................131  Test Your Understanding..........................................................................................................132  Exercises ..................................................................................................................................132  Session 31: Error Handling .......................................................................................................133  Learning Objectives ..................................................................................................................133  Error Handling - Introduction ....................................................................................................133  SQLCA......................................................................................................................................133  DSNTIAR ..................................................................................................................................134  WHENEVER .............................................................................................................................135  Try It Out ...................................................................................................................................136  Summary ..................................................................................................................................139  Test Your Understanding..........................................................................................................139  Exercises ..................................................................................................................................139  Session 33: Commit and Rollback............................................................................................140 

Page 6 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Learning Objectives ..................................................................................................................140  COMMIT ...................................................................................................................................140  Rollback ....................................................................................................................................141  Try It Out ...................................................................................................................................141  Summary ..................................................................................................................................144  Test Your Understanding..........................................................................................................144  Session 35: Cursor .....................................................................................................................145  Learning Objectives ..................................................................................................................145  Cursor - Introduction .................................................................................................................145  Cursor Processing ....................................................................................................................145  Cursor Declaration ....................................................................................................................146  Cursor Open .............................................................................................................................146  Cursor Fetch .............................................................................................................................146  Cursor Close .............................................................................................................................147  Using Cursor for Data Modification...........................................................................................147  Try It Out ...................................................................................................................................148  Summary ..................................................................................................................................151  Test Your Understanding..........................................................................................................151  Exercises ..................................................................................................................................151  Session 42: Handling Null .........................................................................................................152  Learning Objectives ..................................................................................................................152  Null - Introduction......................................................................................................................152  Null Indicator .............................................................................................................................152  Try It Out ...................................................................................................................................153  Summary ..................................................................................................................................161  Test Your Understanding..........................................................................................................161  Exercises ..................................................................................................................................161  Session 46: Handling VARCHAR ..............................................................................................162  Learning Objectives ..................................................................................................................162  VARCHAR - Introduction ..........................................................................................................162  VARCHAR - Behavior ...............................................................................................................162  Try It Out ...................................................................................................................................163  Summary ..................................................................................................................................171  Test Your Understanding..........................................................................................................171  Exercises ..................................................................................................................................171 

Page 7 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Session 51: Locks ......................................................................................................................172  Learning Objectives ..................................................................................................................172  Lock - Introduction ....................................................................................................................172  Table Space - Recap ................................................................................................................172  Simple Table Space .................................................................................................................172  Segmented Table Space ..........................................................................................................173  Partitioned Table Space ...........................................................................................................173  Lock Size ..................................................................................................................................173  Lock Escalation.........................................................................................................................174  Lock Duration............................................................................................................................174  Summary ..................................................................................................................................175  Test Your Understanding..........................................................................................................176  Session 52: Locks ......................................................................................................................177  Learning Objectives ..................................................................................................................177  Lock Mode ................................................................................................................................177  Suspension ...............................................................................................................................179  Timeout .....................................................................................................................................179  Deadlock ...................................................................................................................................179  Constructs that affect locking ...................................................................................................180  Summary ..................................................................................................................................181  Test Your Understanding..........................................................................................................181  Session 54: Miscellaneous ........................................................................................................182  Learning Objectives ..................................................................................................................182  Bind Parameters .......................................................................................................................182  Common SQL Errors ................................................................................................................183  Application Programming Guidelines .......................................................................................184  Using EXPLAIN ........................................................................................................................184  Summary ..................................................................................................................................185  Test Your Understanding..........................................................................................................185  Session 55: Miscellaneous ........................................................................................................186  Learning Objectives ..................................................................................................................186  Table-Based Infrastructure of DB2 ...........................................................................................186  DB2 Catalog .............................................................................................................................186  DB2 Directory ...........................................................................................................................190  Summary ..................................................................................................................................190  Test Your Understanding..........................................................................................................190 

Page 8 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Session 56: Miscellaneous ........................................................................................................191  Learning Objectives ..................................................................................................................191  Utilities - Introduction ................................................................................................................191  Data Consistency Utilities .........................................................................................................191  CHECK Utility ...........................................................................................................................191  REPAIR Utility...........................................................................................................................192  REPORT Utility .........................................................................................................................195  DIAGNOSE Utility .....................................................................................................................195  Backup and Recovery Utilities ..................................................................................................196  COPY Utility ..............................................................................................................................196  MERGECOPY Utility ................................................................................................................197  QUIESCE Utility ........................................................................................................................198  RECOVER Utility ......................................................................................................................199  REBUILD Utility ........................................................................................................................200  REPORT RECOVERY Utility....................................................................................................201  Summary ..................................................................................................................................201  Test Your Understanding..........................................................................................................201  Session 57: Miscellaneous ........................................................................................................202  Learning Objectives ..................................................................................................................202  Data Organization Utilities ........................................................................................................202  LOAD Utility ..............................................................................................................................202  REORG Utility ...........................................................................................................................203  Catalog Manipulation Utilities ...................................................................................................204  CATMAINT Utility......................................................................................................................204  MODIFY Utility ..........................................................................................................................204  RUNSTATS Utility.....................................................................................................................204  STOSPACE Utility ....................................................................................................................205  DB2 Commands .......................................................................................................................206  Summary ..................................................................................................................................209  Test Your Understanding..........................................................................................................209  Session 58: Miscellaneous ........................................................................................................210  Learning Objectives ..................................................................................................................210  Dynamic SQL - Introduction .....................................................................................................210  Dynamic SQL - Types ..............................................................................................................210  When to use Dynamic SQL ......................................................................................................210  Execute Immediate SQL...........................................................................................................210  Non-select dynamic SQL ..........................................................................................................212 

Page 9 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Parameter marker .....................................................................................................................213  Fixed-list select .........................................................................................................................213  Varying-list select SQL .............................................................................................................214  Summary ..................................................................................................................................214  Test Your Understanding..........................................................................................................214  Session 59: Miscellaneous ........................................................................................................215  Learning Objectives ..................................................................................................................215  Stored Procedure - Introduction ...............................................................................................215  Stored Procedure - Development .............................................................................................215  Creating Stored Procedures .....................................................................................................216  Managing Stored Procedures ...................................................................................................217  Executing a Stored Procedures ................................................................................................217  Summary ..................................................................................................................................218  Test Your Understanding..........................................................................................................218  Glossary ......................................................................................................................................219  References ..................................................................................................................................227  Websites ...................................................................................................................................227  Books ........................................................................................................................................227  STUDENT NOTES: ......................................................................................................................228 

Page 10 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Introduction About this Module This module deals with the fundamentals of DB2.

Target Audience This module is specifically aimed at entry level trainees.

Module Objectives After completing this module, you will be able to: ‰

Explain the introduction to DB2 Objects

‰

Explain Database Design

‰

Describe Data Integrity

‰

Identify the Interaction with DB2

‰

Describe SQL

‰

Explain the introduction of simple COBOL DB2 application program

‰

Identify Error Handling

‰

Explain Commit and Rollback

‰

Explain Cursor

‰

Handle NULL

‰

Handle VARCHAR

‰

Define Locks

‰

State Application Programming Guidelines

Pre-requisite To follow the course successfully, a trainee needs to have a prior theoretical as well as hands-on knowledge of the following: ‰

TSO/ISPF

‰

COBOL

‰

JCL

‰

VSAM

Page 11 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 02: Introduction to DB2 Objects Learning Objectives After completing the session, you will be able to: ‰

Identify the different DB2 objects

‰

Explain the relation between DB2 objects

‰

Describe how the data is being stored in DB2 physically

Database A database is a collection of data stored in some organized fashion. The simplest way to think of it is to imagine a database as a filing cabinet. The filing cabinet is simply a physical location to store data, regardless of what that data is or how it is organized. You will see about Database in detail in the later part of this session. Database: A container (usually a file or set of files) to store organized data.

DBMS A Database Management System (DBMS) is a set of programs designed for the purpose of managing databases. Typical examples of DBMS include: ‰

DB2

‰

Oracle

‰

Microsoft Access

‰

Microsoft SQL Server

Database Model A database model refers to the way a DBMS organizes information internally. It is a theory or specification, describing how a database is structured and used. Common models include the following: ‰

Hierarchical model

‰

Network model

‰

Relational model

‰

Object model

Page 12 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 RDBMS Relational Database Management System (RDBMS) is a type of database management system (DBMS) that stores data in the form of related tables. Most popular RDBMS includes: ‰

DB2

‰

Oracle

‰

Microsoft SQL Server

DB2 DB2 or Database 2 is a Relational Database Management System offered by IBM that runs on IBM Mainframe, AS/400 and on PC. A DB2 database can grow from a small single-user application to a large multi-user system.

Storage Group A DB2 storage group (STOGROUP) is a set of volumes on direct access storage devices (DASD). The volumes hold the VSAM data sets in which tables and indexes are actually stored. Max no of volumes per Storage group is 133 (Ideally 3 or 4). All volumes of a given storage group must have the same device type (3380, 3390, and so no.). But, parts of a single database can be stored in different storage groups. If the volumes in a storage group are different types or if any volume is not mounted or is otherwise invalid, then an error will occur when you try to create a table space or index. Try to assign frequently accessed objects (indexes, for instance) to fast devices and seldom-used tables to slower devices; that choice of storage groups improves performance. After you define a storage group, DB2 stores information about it in the DB2 catalog. (This catalog is not the same as the integrated catalog facility catalog that describes DB2 VSAM data sets). The catalog table SYSIBM.SYSSTOGROUP has a row for each storage group and SYSIBM.SYSVOLUMES has a row for each volume. At installation, the system default storage group is defined. This storage group is named SYSDEFLT. If you do not explicitly manage your storage, then DB2 uses the default storage group to allocate space.

Page 13 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Following figure represents the physical representation of storage group.

Database in detail A database is a collection of related data tables or entities. For example, a typical database for an organization would consist of a customer, an order, and order details tables. All these tables are related to one another in some way. In this example, customers have orders and orders have order details. Even though each table exists on its own, collectively the tables comprise a database. Database is a group of logically related Tablespaces and Indexspaces, which in turn contain tables and indexes respectively. The default database, DSNDB04, is predefined in the DB2 installation process.

Table Space Data is actually stored in a structure known as a table space. Each table space correlates to one or more individual physical VSAM data sets in the DASD volumes of storage Group. Each table space contains one or more tables. There are three different types of table space: ‰

Simple table space

‰

Segmented table space

‰

Partitioned table space

You will talk about table space in detail while dealing with “Locks”.

Page 14 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Index Space An index space is the underlying storage structure for index data. Each index space correlates to one or more individual physical VSAM data sets in the DASD volumes of storage Group. It is automatically created by DB2 whenever an index is created. There can only be one index in an index space.

Table Tables are logical structures maintained by the database manager. When you store information in your filing cabinet you do not just toss it in a drawer. Rather, you create files within the filing cabinet, and then you file related data in specific files. In the database world, that file is called a table. A table is a structured file that can store data of a specific type. A table might contain a list of customers, a product catalog, or any other list of information. Each table has a name, and within a table, each column has a name. No particular ordering is maintained among the rows of a table, but rows can be retrieved in an order determined by values in their columns. The data in a table is logically related. All table data is assigned to table spaces. A table consists of data logically arranged in columns and rows.

Column Tables are made up of columns. A column contains a particular piece of information within a table. Column is a single field in a table. All tables are made up of one or more columns. The best way to comprehend this is to envision database tables as grids, somewhat like spreadsheets. Each column in the grid contains a particular piece of information. In a customer table, for example, one column contains the customer number, another contains the customer name, and the address, city, state, and zip are all stored in their own columns.

Row ‰

Data in a table is stored in rows.

‰

Row is a record in a table.

‰

Again, envisioning a table as a spreadsheet style grid, the vertical columns in the grid are the table columns, and the horizontal rows are the table rows.

Page 15 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 For example, a customer table might store one customer per row. The number of rows in the table is the number of records in it.

Table Terminology Following table will give the terminology used in table context: In this Document

Formal Terms

Many Database Manuals

Table

Relation

Table

Column

Attribute

Field

Row

Tuple

Record

Types of Table Base Table: A base table is created with the CREATE TABLE statement and is used to hold persistent user data. Result Table: A result table is a set of rows that the database manager selects or generates from one or more base tables to satisfy a query. Summary Table: A summary table is a table defined by a query that is also used to determine the data in the table. Summary tables can be used to improve the performance of queries. If the database manager determines that a portion of a query can be resolved using a summary table, the database manager can rewrite the query to use the summary table. Temporary Table: A declared temporary table is created with a DECLARE GLOBAL TEMPORARY TABLE statement and is used to hold temporary data on behalf of a single application. This table is dropped implicitly when the application disconnects from the database

Index An index is a data access aid that can be created on a table. It is an ordered set of pointers to rows in a table. Each index is based on the values of data in one or more columns in a table. An index is an object that is separate from the data in the table. When you create an index, the database manager builds the structure and maintains it automatically.

Page 16 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 An index can serve the following purposes: ‰

Improve performance. In most cases, access to data is faster with an index. Provides a fast way to find rows in a table based on their values in the key columns.

‰

Enforces uniqueness rules by defining a column or group of columns as a unique index or primary key.

‰

Provides a logical ordering of the rows of a table based on the key column values.

‰

Clusters the rows of a table in physical storage according to the order of the defined index.

View A view provides a different way of looking at the data in one or more tables. View is a virtual table consisting of a SQL SELECT statement that accesses data from one or more tables or views. A view never stores data. When you access a view, the SQL statement that defines it is executed to derive the requested data. A view has columns and rows just like a base table. All views can be used just like base tables for data retrieval. You can use views to control access to sensitive data, because views allow multiple users to see different presentations of the same data. For example, several users may be accessing a table of data about employees. A manager sees data about her employees but not employees in another department. A recruitment officer sees the hire dates of all employees, but not their salaries; a financial officer sees the salaries, but not the hire dates. Each of these users work with a view derived from the base table. Each view appears to be a table and has its own name. When the column of a view is directly derived from the column of a base table, that view column inherits any constraints that apply to the base table column. For example, if a view includes a foreign key of its base table, insert and update operations using that view are subject to the same referential constraints as is the base table. Also, if the base table of a view is a parent table, delete and update operations using that view are subject to the same rules as are delete and update operations on the base table. A view can become inoperative (for example, if the base table is dropped); if this occurs, the view is no longer available for SQL operations. The best way to recognize views is to look at an example. (You will study about the SQLs in detail further. This example is just to make you understand the concept of views). You have following three tables: ‰

Customers

‰

Orders

‰

OrderDetails

Page 17 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 You need to retrieve the customers who had ordered a specific product. The column details are as follows. Table

Column cust_id

Customers

cust_name cust_contact order_num

Orders cust_id order_num OrderDetails prod_id The query is as follows: SELECT cust_name, cust_contact FROM Customers, Orders, OrderDetails WHERE Customers.cust_id = Orders.cust_id AND OrderDetails.order_num = Orders.order_num AND prod_id = 'RGAN01'; Anyone needing this data would have to understand the table structure, as well as how to create the query and join the tables. To retrieve the same data for another product (or for multiple products), the last WHERE clause would have to be modified. Now imagine that you could wrap that entire query in a virtual table called ProductCustomers. You could then simply do the following to retrieve the same data: SELECT cust_name, cust_contact FROM ProductCustomers WHERE prod_id = 'RGAN01'; This is where views come into play. ProductCustomers is a view, and as a view, it does not contain any columns or data. Instead it contains a query—the same query used above to join the tables properly. Why Use Views: Here are some common uses of views: ‰

To draw data from multiple tables.

‰

To reuse SQL statements.

‰

To simplify complex SQL operations. After the query is written, it can be reused easily, without having to know the details of the underlying query itself.

‰

To expose parts of a table instead of complete tables.

‰

To secure data. Users can be given access to specific subsets of tables instead of to entire tables.

Page 18 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

To change data formatting and representation. Views can return data formatted and presented differently from their underlying tables.

For the most part, after views are created, they can be used in the same way as tables. You can perform SELECT operations, filter and sort data, join views to other views or tables, and possibly even add and update data. There are some restrictions on this last item. The important thing to remember is views are just that, views into data stored elsewhere. Views contain no data themselves, so the data they return is retrieved from other tables. When data is added or changed in those tables, the views will return that changed data. There are some performance issues with views because views contain no data, any retrieval needed to execute a query and that must be processed every time the view is used. If you create complex views with multiple joins and filters, or if you nest views, you may find that performance is dramatically degraded. Be sure you test execution before deploying applications that use views extensively.

Synonym 1. An alternative, private name for a table or view. 2. A synonym can be used only by the individual who creates it. When a table or view is dropped, all synonyms defined on it are also dropped

Alias 1. A locally defined name for a table or view in the same local DB2 subsystem or in a remote DB2 subsystem. Aliases give DB2 location independence because an alias can be created for a table at a remote site, thereby freeing the user from specifying the site that contains the data. Aliases can be used also as a type of global synonym because they can be accessed by anyone, not only by their creator. 2. When a table/view is dropped, all aliases defined on it are NOT dropped 3. Use Synonyms for Program Development, use Aliases for Distributed Applications and use Views for security and joining. Following table gives the difference between “Synonym” and “Alias” Synonym

Alias

An alternative name for a table or view which should An alternative name for a table or view which can reside in the local DB2 subsystem reside in the local or remote DB2 subsystem Can be used only by its creator

Can be used by anyone including its creator

Is dropped when it’s corresponding Table/View is dropped

Not dropped even when it’s corresponding Table/View is dropped

Page 19 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Physical Storage of Data The following figure represents how the data is physically stored in DB2 system.

Hierarchy of DB2 Objects Following figure represents the hierarchy of DB2 objects:

Page 20 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Buffer Pool Buffer pools are areas of virtual storage in which DB2 temporarily stores pages of table spaces or indexes. Buffer pools improve database performance. If a needed page of data is already in the buffer pool, that page is accessed faster than if that page had to be read directly from disk. The database manager has agents whose tasks are to retrieve data pages from disk and place them in the buffer pool (pre-fetchers), and to write modified data pages from the buffer pool back to disk (page cleaners). The reading and writing of data pages to and from disk is called disk input/output (I/O). Avoiding the wait associated with disk I/O is the primary way to improve the performance of the database. How you create the buffer pool, and configure the database manager and the agents associated with the buffer pool, controls the performance of the database. In DB2, you have the option of allocating 80 Buffer Pools: ‰

50 4K buffer pools and

‰

10 8K, 16K and 32K buffer pools.

The default buffer pool is BP0.

Summary ‰

Storage Group is a set of volumes on DASD which contains VSAM datasets.

‰

Database is a collection of related data elements.

‰

Table space represents one or more tables which correlate to one or more VSAM data sets in the DASD volumes of storage Group.

‰

Index Space represents an index correlates to one or more VSAM data sets in the DASD volumes of storage Group.

‰

Table consists of data logically arranged in columns and rows.

‰

Index is an ordered set of pointers to rows in a base table.

‰

View is a virtual table that accesses data from one or more tables or views.

‰

Synonym is an alternative name for a table or view which should reside in the local DB2 subsystem.

‰

Alias is an alternative name for a table or view, which can reside in the local or remote DB2 subsystem.

‰

Buffer Pools are areas of virtual storage in which DB2 temporarily stores pages of table spaces or indexes.

Page 21 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

What is a storage group? What is a database? What is a table space? What is an index space? What is a table? What is an index? What is a View? What is the difference between Synonym and Alias? State the logical and physical objects among the DB2 objects and their hierarchy. How the data is being stored physically? What is a buffer pool?

Page 22 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 03: Database Design Learning Objectives After completing the session, you will be able to: ‰

Design a DB2 database

Why Should You Be Concerned with Database Design? You will look at the concept of database design with the real life example. Say your database is like a custom home and that you are going to have one built for us. What is the first thing you are going to do? Certainly you are not going to hire a contractor immediately and let him build our home however he wishes. Surely you will first engage an architect to design your new home and then hire a contractor to build it. The architect will express your needs as a set of blueprints, recording decisions about size and shape, and requirements for various systems (structural, mechanical, electrical). Next the contractor will procure the labor and materials, including the listed systems, and then assemble them according to the drawings and specifications. Now let’s return to your database perspective and think of the logical database design as the architectural blueprints and the physical database implementation as the completed home. The logical database design describes the size, shape, and necessary systems for a database; it addresses the informational needs and operational needs of your business. You then build the physical implementation of the logical database design, using your RDBMS software program. Once you have created your tables, set up table relationships, and established the appropriate levels of data integrity, our database is complete. Now you are ready to create an application that allows interacting easily with the data stored in the database and you can be confident that these applications will provide with timely and above all, accurate information. It is possible to implement a poor design in an RDBMS, but a well designed database will yield accurate information, store data more efficiently and effectively, and will be easier to manage and maintain. If a database is designed improperly, users will have difficulty in retrieving certain types of information, and there is the added risk that searches will produce inaccurate information. Inaccurate information is probably the most detrimental result of improper database design. It can adversely affect the bottom line of a business. In fact, if the data kept and used in a database is going to affect the way a business performs its day-to-day operations or if it's going to influence the future direction of the business, database design must be a concern.

Activities involved in Database Design Designing the database involves: ‰

Logical Database Design

‰

Physical Database Design

Page 23 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

Implementing and Altering Database Design

Logical Database Design Logical database design involves three phases: ‰

Requirements analysis phase

‰

Data modeling phase

‰

Normalization phase

Requirements Analysis Phase The requirements analysis phase involves examining the business being modeled, interviewing users and management to assess the current system and to analyze future needs, and determining information requirements for the business as a whole. This process is relatively straightforward. Data Modeling Phase The data modeling phase involves modeling the database structure itself. This involves using a data modeling method which provides a means of visually representing various aspects of the database structure, such as the tables, table relationships, and relationship characteristics. Some of the common data modeling methods are: ‰

Entity Relationship modeling (ER modeling)

‰

Semantic object modeling

‰

Object role modeling

The method which you use here is a basic version of ER modeling. ER Modeling A simple ER Diagram looks as follows.

This figure represents several aspects of the database. First, it conveys the fact that there are two tables in this database, one called Agents and the other called Clients; each of the tables is represented by a rectangle. The diamond represents the fact that there is a relationship between these two tables, and the "1:N" within the diamond indicates that the relationship is a one-to-many relationship. Finally, the diagram conveys the fact that a client must be associated with an agent (indicated by the vertical line next to the AGENTS table), but an agent does not necessarily have to be associated with a client (as indicated by the circle next to the CLIENTS table). An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database of a Logical data modeling.

Page 24 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Symbols used in ER Diagram: ‰

Box represents Entity

‰

Diamond represents Relationship

‰

Oval represents Attribute

Key Activities in ER Modeling: Following are the key activities involved in designing Logical database using Entity-Relationship Mode: ‰

Define Entities

‰

Define Primary Key

‰

Define Relationships among Entities

‰

Define Additional Attributes for the Entities

Define Entities: ‰

You begin the ER Model, by defining the entities, the significant objects of interest

‰

Entities are the things about which you want to store information.

Define Primary Key: ‰

A primary key is a unique identifier for an Entity.

‰

If a primary key is made up of more than one attribute, then it is called as “Composite Key”.

Define Relationships among Entities A connection established between a pair of tables is known as a relationship. A relationship exists when a pair of tables is connected by a Primary key and a foreign key or is linked together by a third table, known as a linking table. Relationships are very important because they help to reduce redundant data and duplicate data. They also provide the means to define views. Every relationship can be characterized by the type of relationship that exists between the tables, the type of participation each table has within the relationship, and the degree of participation each table has within the relationship. Types of Relationships (Cardinality): When two tables are related, there is always a specific type of relationship (traditionally known as cardinality) that exists between them. There are three possible types of relationships: ‰

one-to-one

‰

one-to-many and many-to-one relationships

‰

many-to-many

Page 25 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 One-to-One Relationships: A one-to-one relationship exists between a pair of tables if a single record in the first table is related to only one record in the second table and a single record in the second table is related to only one record in the first table. Following figure shows an example of a one-to-one relationship involving an EMPLOYEES table and a COMPENSATION table. In this example, a single record in the EMPLOYEES table is related to only one record in the COMPENSATION table; likewise, a single record in the COMPENSATION table is related to only one record in the EMPLOYEES table.

One-to-Many Relationships: A one-to-many relationship exists between a pair of tables if a single record in the first table can be related to one or more records in the second table, but a single record in the second table can be related to only one record in the first table. A one-to-many relationship involving a STUDENTS table and an INSTRUMENTS table is shown in the following figure. In this case, a single record in the STUDENTS table can be related to one or more records in the INSTRUMENTS table, but a single record in the INSTRUMENTS table is related to only one record in the STUDENTS table.

Page 26 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Many-to-One Relationships A many-to-one relationship exists between a pair of tables if a single record in the first table can be related to only one record in the second table, but a single record in the second table can be related to one or many records in the first table. A many-to-one relationship involving an EMPLOYEE table and a DEPARTMENT table is shown in the following figure. In this example, a single record in the EMPLOYEE table can be related to only one record in the DEPARTMENT table and a single record in the DEPARTMENT table can be related to one or more records in the EMPLOYEE table. Following figure represents many-to-one relationship. Here a relationship is established between two tables with the help of a linking table.

Page 27 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Many-to-Many Relationships: A many-to-many relationship exists between a pair of tables if a single record in the first table can be related to one or more records in the second table, and a single record in the second table can be related to one or more records in the first table. Following figure shows a classic many-to-many relationship. In this example, a single record in the STUDENTS table can be related to one or more records in the CLASSES table; likewise, a single record in the CLASSES table can be related to one or more records in the STUDENTS table. Following figure represents many-to-many relationship. Here a relationship is established between two tables with the help of a linking table.

Types of Participation (Optionality): There are two types of participation that a table can have within a relationship: ‰

Mandatory

‰

Optional

Say there is a relationship between two tables called TABLE A and TABLE B. If records in TABLE A must exist before any new records can be entered into TABLE B, TABLE A's participation within the relationship is mandatory. However, if it is not necessary for records in TABLE A to exist in order to enter any new records into TABLE B, TABLE A's participation within the relationship is optional. Each table within a relationship can participate in either manner. The type of participation each table has within a relationship is typically determined by the way the data in each table is related and how the data is being used.

Page 28 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Consider the relationship between the AGENTS and CLIENTS tables in the following figure. The AGENTS table has a mandatory participation within the relationship if agents must exist before a new client can be entered into the CLIENTS table. But the AGENTS table's participation is optional if it isn't necessary to have agents in the AGENTS table before a new client can be entered into the CLIENTS table. The type of participation established for the AGENTS table is determined by the way its data is being used in relation to the data in the CLIENTS table. For example, if it is necessary to ensure that each client is assigned an available agent, then the participation of the AGENTS table within the relationship should be mandatory.

Representation of Cardinality and Optionality: In general the following conventions are being used for representing cardinality and optionality, Cardinality: ‰

The notion of cardinality is expressed as either "one" or "many"

‰

A cardinality of “one” is expressed as a “straight line” and a cardinality of “many” is expressed using “crow's feet”.

Optionality: ‰

The notion of optionality is expressed as either "mandatory" or "optional"

‰

An optionality of “Optional” is expressed as a “circle” and an optionality of “Mandatory” is expressed as a “vertical bar”.

Sample ER Diagram: Consider the example of a database that contains information on the residents of the cities. The ER Diagram contains two Entities – Person and City. Optionality: A person should live in a city. (That is why a bar appears adjacent to City from Person). A City can exist without a person. (That is why a circle appears adjacent to Person in the “City – Person Relationship”).

Page 29 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Define Additional Attributes for the Entities: Defining the attributes for an entity includes the following activities. ‰

Defining attribute name.

‰

Defining Data Type for the attributes.

‰

Defining appropriate values for the attributes - what values are acceptable for the various attributes of a table.

Normalization: Normalization is a design approach that minimizes data redundancy and optimizes data structures by systematically and properly placing data elements into the appropriate groupings. Normalization is the process of efficiently organizing data in a database and is the process of decomposing large tables into smaller tables. Goals of Normalization: There are two goals of the normalization process: ‰

Eliminating redundant data (for example, storing the same data in more than one table)

‰

Ensuring data dependencies make sense (only storing related data in a table).

Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored and avoid problems with inserting, updating, or deleting data. Normal Form: A series of guidelines were developed by the database community for ensuring that the databases are normalized. Those guidelines are represented by different normal forms. Types of Normal forms are as follows: ‰

First Normal Form or 1NF

‰

Second normal Form or 2NF

‰

Third Normal Form or 3NF

‰

Fourth Normal Form or 4NF

‰

Fifth Normal Form or 5NF

Page 30 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 In practical applications, in general, you use only 1NF, 2NF, and 3NF. First Normal Form: ‰

All entities must have a unique identifier or key, that can be composed of one or more attributes.

‰

Eliminate repeating groups and non-atomic data from an entity.

The term atomic derives from atom, the smallest indivisible particle that can exist on its own. First normal form eliminates repeating groups and non-atomic data from an entity. To normalize a data model into 1NF, eliminate repeating groups into individual entities. In other words, do not use multiple attributes in a single entity to store similar data. Consider the sample data shown in table for a STUDENT information system for a college or university. This data contains several violations of 1NF. First, you are tracking courses that really represent a repeating group for STUDENTs. So, the course information should be moved into separate entities. Furthermore, you need to specify identifiers for both entities. The identifier is the primary key for the entity. A second violation of 1NF is the non-atomic data shown in the StudentName attribute. A student name can be broken down into pieces: first name, middle initial and last name. It is not indivisible, and therefore violates first normal form. Unnormalized STUDENT Data StudentID

StudentName

MajorID

StudentMajor

CourseNum

CourseName

CourseCompDate

2907

Smith, Jacob R

MAT

Mathematics

MAT0011

Discrete Math

8/1/2002

MAT0027

Calculus I

4/30/2002

EGL0010

English Classics I

12/30/2001

4019

Patterson, Jane K

PHI

Philosophy

PHI0010 CS00100

Intro to Philosophy Programming Languages

2002-04-30 200204-30

5145

Neeld, Norris B

EGL

English Literature

SOC0102

Ascent of Man

8/1/2002

6132

Morrison, Xavier Q

MUS

Music

MUS0002 SOC0102

Origin of Jazz Ascent of Man

2002-04-30 200208-01

7810

Brown, Richard E

CS

Computer Science

8966

Juarez, Samantha

EGL

English Literature

EGL0010 EGL0101

English Classics I Shakespeare II

2001-12-30 200208-01

Page 31 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

STUDENT Entity in 1NF StudentID

LastName

FirstName

MiddleInit

MajorID

StudentMajor

2907

Smith

Jacob

R

MAT

Mathematics

4019

Patterson

Jane

K

PHI

Philosophy

5145

Neeld

Norris

B

EGL

English Literature

6132

Morrison

Xavier

Q

MUS

Music

7810

Brown

Richard

E

CS

Computer Science

8966

Juarez

Samantha

EGL

English Literature

COURSE Entity in 1NF StudentID

CourseNum

CourseName

CourseCompDate

2907

MAT0011

Discrete Math

8/1/2002

2907

MAT0027

Calculus I

4/30/2002

2907

EGL0010

English Classics I

12/30/2001

4019

PHI0010

Intro to Philosophy

4/30/2002

4019

CS00100

Programming Languages

4/30/2002

5145

SOC0102

Ascent of Man

8/1/2002

6132

MUS0002

Origin of Jazz

4/30/2002

6132

SOC0102

Ascent of Man

8/1/2002

8966

EGL0010

English Classics I

12/30/2001

8966

EGL0101

Shakespeare II

8/1/2002

Second Normal Form: ‰

Should be in First Normal Form

‰

Every non-key attribute is fully dependent on the key

Second normal form (2NF) ensures that all the attributes of each entity are dependent on the primary key. Notice that certain courses repeat in the COURSE entity, namely "English Classics I" and "Ascent of Man." This situation indicates a violation of 2NF. To correct the problem, we need to identify the attributes that do not depend on the entire key and remove them. The removed attributes, along with the portion of the primary key on which they depend, are placed in a new entity, ENROLLMENT. The entire primary key of the original entity remains with the original entity. Another benefit of the normalization process is that you will frequently encounter new attributes that need to be specified for the new entities that are created. For example, perhaps the new COURSE entity causes us to remember that each course is assigned a number of credits that count toward graduation. No changes were required for the STUDENT entity:

Page 32 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

ENROLLMENT Entity in 2NF StudentID

CourseNum

CourseCompDate

2907

MAT0011

2002-08-01

2907

MAT0027

2002-04-30

2907

EGL0010

2001-12-30

4019

PHI0010

2002-04-30

4019

CS00100

2002-04-30

5145

SOC0102

2002-08-01

6132

MUS0002

2002-04-30

6132

SOC0102

2002-08-01

8966

EGL0010

2001-12-30

8966

EGL0101

2002-08-01

COURSE Entity in 2NF CourseNum

CourseName

Credits

MAT0011

Discrete Math

3

MAT0027

Calculus I

4

EGL0010

English Classics I

3

PHI0010

Intro to Philosophy

3

CS00100

Programming Languages

3

SOC0102

Ascent of Man

3

MUS0002

Origin of Jazz

3

Page 33 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Third Normal Form: ‰

Should be in Second Normal Form

‰

Every non-key attribute is non-transitively dependent on the primary key that is, every attribute in the entity should depend only on the key not on any other non-key attributes.

A rule of thumb for identifying 3NF violations is to look for groups of attributes whose values can apply to more than a single entity occurrence. When you discover such attributes, move them to a separate entity. It is time to review our STUDENT information again, this time looking for 3NF violations. Examine the STUDENT data in closely. Notice that students can have the same major and, as such, certain major information can be repeated, specifically two students in our small sample are English Literature majors. To correct the problem, we need to remove major attributes that transitively depend on the key and create a new entity for them. STUDENT Entity in 3NF StudentID

LastName

FirstName

MiddleInit

MajorID

2907

Smith

Jacob

R

MAT

4019

Patterson

Jane

K

PHI

5145

Neeld

Norris

B

EGL

6132

Morrison

Xavier

Q

MUS

7810

Brown

Richard

E

CS

8966

Juarez

Samantha

EGL

MAJOR Entity in 3NF MajorID

StudentMajor

MAT

Mathematics

PHI

Philosophy

EGL

English Literature

MUS

Music

CS

Computer Science

A Normalized Data Model: To be complete, a diagram should be developed for the 3NF data model we just created for the STUDENT data. Figure shows such a data model. Notice that we have not filled in the optionality of the relationships. We could do this based on the sample data we used, but we really need to ask more questions before we can answer questions such as Does a every student have to have a major? The current data shows this to be the case, but in reality; you know that most freshmen, and even upperclassmen, may attend college without having a formally declared major.

Page 34 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 The STUDENT data model

Further Normal Forms: Normalization does not stop with 3NF. Additional normal forms have been identified and documented. However, normalization past 3NF does not occur often in normal practice. The following are additional normal forms. Just for your information we’ve kept this. Boyce Codd normal form (BCNF) is a further refinement of 3NF. Indeed, in his later writings Codd refers to BCNF as 3NF. A row is in Boyce Codd normal form if and only if every determinant is a candidate key. Most entities in 3NF are already in BCNF. Fourth normal form (4NF) states that no entity can have more than a single one-to-many relationship if the one-to-many attributes are independent of each other. An entity is in 4NF if and only if it is in 3NF and has no multiple sets of multivalued dependencies. Fifth normal form (5NF) specifies that every join dependency for the entity must be a consequence of its candidate keys.

Page 35 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Physical database design After completing the logical design of our database, we now move to the physical design. The purpose of building a physical design of our database is to optimize performance while ensuring data integrity by avoiding unnecessary data redundancies. During physical design, you transform the entities into tables, the instances into rows, and the attributes into columns. You must decide on many factors that affect the physical design, some of which are listed as follows: ‰

How to translate entities into physical tables

‰

What attributes to use for columns of the physical tables

‰

Which columns of the tables to define as keys

‰

What indexes to define on the tables

‰

What views to define on the tables

‰

How to denormalize the tables

‰

How to resolve many-to-many relationships

Physical design is the time when you abbreviate the names that you chose during logical design. For example, you can abbreviate the column name that identifies employees, EMPLOYEE_NUMBER, to EMPNO. The task of building the physical design is a job that truly never ends. You need to continually monitor the performance and data integrity characteristics of the database as time passes. Many factors necessitate periodic refinements to the physical design. Denormalization: Denormalization is a key step in the task of building a physical relational database design. It is the intentional duplication of columns in multiple tables, and the consequence is increased data redundancy. This is recommended to avoid performance problems occur as a result of normalization. This should be done based on the processing needs of applications accessing the data.

Page 36 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Implementing and Altering Database Design Implementing the database design involves: ‰

Implementing DB2 objects

‰

loading data

‰

managing data

‰

altering the design as necessary

Altering Database Design: ‰

After using a relational database for a while, we might want to change some aspects of its design.

‰

To alter the database design we need to change the definitions of DB2 objects.

Advantage of DB2 over VSAM The following list will give some of the advantages of DB2 over VSAM. Feature Hardware Independence

DB2

VSAM

PC to mainframe

Only Mainframe

NT, Unix and OS/390

Only OS/390

Standard SQL

Not so simple

Stored procedure & triggers

No such option

Standard SQL

Difficult

High degrees of security

Only at Dataset level

DB2 enforces it

Developers responsibility

Easy to view/modify

Not available

Better for even large data

Better when data is less

Optimizer handles

Developer responsible

Can be tuned anytime

Depends on initial design

Can be at SQL level

Only application level

Tools available for aiding

No tuning aids

Abundant tuning skills

Tuning skills are rare

Direct reorganization

Delete & recreate

Online reorg possible

Downtime needed

Managed by DB2

Managed by CICS/IMS

Always recoverable

No recovery in batch

From log / backup

From backup only

Auto Recovery

Manual Restore

Online backup possible

Downtime needed

Incremental backup

No incremental backup

Disaster Recovery

Supported by DB2

Part of DASD recovery

Data Archival

Selective archival

No Selective archival

OS Independence Ease of development

Ease of maintenance Security Referential Integrity Query Interface Performance

Performance Tuning

Reorganization

Recovery

Backup

Page 37 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Feature

DB2

Data types

VSAM

Selective retrieval

No Selective retrieval

Up to row level archival

Dataset level archival

Images, Video, Audio, and so on.

Text only

Contents can be in file

No such option

Summary ‰

Database Design involves: o o o

‰

Logical Database Design Physical Database Design Implementing and Altering Database Design

Key activities for designing Logical data modeling with Entity-Relationship Model are: o Define Entities o Define Primary Key:

o

Unique identifier Composite Key: Key made up of more than one attributes Define Relationships among Entities: One-to-one relationships One-to-many and many-to-one relationships Many-to-many relationships Cardinality: Number of occurrences between the entities. Optionality: Relationships are mandatory or optional Define Additional Attributes for the Entities

‰

Normalization: Eliminating redundant data thereby reducing the amount of space o Three Normal Forms: 1NF, 2NF, and 3NF

‰

Physical database design is transformation of: o o o o

‰

Entities into tables Instances into rows Attributes into columns Denormalization is recommended to avoid performance problems occur as a result of normalization

Implementing the database design involves: Implementing DB2 objects, loading and managing data and altering the design as necessary. o Altering Database Design: To alter the database design, you need to change the definitions of DB2 objects

Test Your Understanding 1. 2. 3. 4. 5. 6.

What are the tasks involved in database design? What is logical data modeling? What is ER Model? What are all the symbols used in ER model? Describe the key activities involved in designing logical data modeling using ER model? What is a Primary key?

Page 38 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 7. 8. 9. 10. 11. 12. 13. 14. 15.

What are all the different types of relationship? What is Cardinality and Optionality? What is Normalization? What are the goals and benefits of Normalization? State the different types of Normal forms. Describe the tasks involved in the physical database design. When will you do Denormalization? State the activities involved in implementing and altering database design. List some of the advantages of DB2 over VSAM.

Exercises Following figure represents the “Medical Bill” to be produced to a customer. Design a Database for the medical shop system.

Page 39 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 07: Data Integrity Learning Objectives After completing the session, you will be able to: ‰

Identify different means of achieving data integrity across the database by DB2

Introduction to Data Integrity Data integrity refers to the validity, consistency, and accuracy of the data in a database. It cannot be overstated that the level of accuracy of the information retrieved from the database is in direct proportion to the level of data integrity imposed within the database. Data integrity is one of the most important aspects of the database design process, and it should not be underestimated, overlooked, or even partially neglected. To make any of these mistakes would result in a high risk of undetectable errors. There are three types of data integrity and are as follows: ‰

Entity Integrity

‰

Referential Integrity

‰

Domain Integrity

Entity Integrity This is the “Table-level integrity” which ensures that the field that identifies each record within the table is unique and is never missing its value. Entity integrity requires the specification of a primary key (PK) for each table. Key Notes about Primary Key: ‰

Each table can have zero or one primary key.

‰

Primary key should not be Null and if the primary key is a composite key, make sure that each component should not be Null.

‰

Every primary key explicitly defined for a table must be associated with a corresponding unique index.

‰

If you do not create a unique index for a primary key, then an incomplete key is defined for the table, making the table inaccessible.

Unique Constraint: A unique constraint is similar to a primary key constraint which also enforces unique values on an individual or a group of columns. Each table can have zero, one, or many unique constraints consisting of one or more columns each. The values stored in the unique column, or combination of columns, must be unique within the table. Unique constraint column should not be Null. A unique index needs to be created on the columns of the unique constraint to ensure uniqueness. The only difference between Primary Key constraint and Unique Constraint is a table can have only one primary key constraint but can have more than one unique constrains.

Page 40 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Unique Index: In addition of creating unique index in primary key column or unique constraint column (which is mandatory), you can create as many unique indexes as we need on any other columns of the table to ensure uniqueness. The following table will show the difference between unique index on Primary Key/Unique constraint column and other column other than primary/unique constraint column. Primary Key or unique constraint column

Column other than primary/unique constraint but defined with unique index

A table can contain only one primary key constraint and multiple unique constraints

A table can contain multiple unique indexes

Cannot allow NULL values

Can allow NULL values

Supports Referential Integrity

Cannot support Referential Integrity

Referential Integrity This is a “Relationship-level integrity” which ensures that the relationship between a pair of tables is sound and that there is synchronization between the two tables whenever data is entered, updated, or deleted. Referential integrity is achieved through the foreign key. Foreign Key: A foreign key (FK) is a column or combination of columns used to establish and enforce a link between the data in two tables. A link is created between two tables by adding the column or columns that hold one table's primary key values to the other table. This column becomes a foreign key in the second table. The table with the primary key is called parent table and the table with the foreign key is called dependent table (or child table). Referential integrity (RI) means each row in a dependent table must have a foreign key that is equal to a primary key in the parent table.

Rules ensuring RI: Insert: When inserting a row with a foreign key in the dependent table, DB2 checks the values of the foreign key column against the values of the primary key column in the parent table. If there is a matching primary key column, the insert is allowed. If there is no matching primary key column, the insert will not happen. A new row can be inserted in the parent table as long as the primary key value of the new row is unique.

Page 41 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Update: When updating foreign key values in the dependent table, DB2 checks whether there is a matching primary key in the parent table or not. If there is a matching primary key, update is allowed. If there is no matching primary key, update is not allowed. The primary key in the parent table cannot be updated if any rows in the dependent tables refer to it. Delete: Deleting a row with a foreign key in the dependent table is permitted. When deleting a row with a primary key in the parent table, DB2 takes one of the following actions as indicated while defining the table. RESTRICT: Disallows the deletion of the primary key row if any foreign keys relate to that row. CASCADE: Allows the deletion of the primary key row and also deletes the foreign key rows that relate to it. SET TO NULL: Allows the deletion of the primary key row and, instead of deleting all related foreign key rows, sets the foreign key columns to NULL. Operation

Child Table

Parent Table

Insert

Allowed if the foreign key value matches the value of Primary key of the parent table.

Allowed as long as the primary key value is unique.

Update

Allowed if the foreign key value matches the value of Primary key of the parent table.

Allowed if there are no foreign key references in the child tables.

Delete

Allowed.

Depending upon the action specified during table definition. Restrict: not allowed if there are any foreign key references Cascade: allowed and deletes the foreign key references if any in the child tables. SET TO NULL: allowed and a Null value will be set in the foreign key references of the child tables

Domain Integrity This is the “Field-level integrity” which ensures that the structure of every field is sound, that the values in each field are valid, consistent, and accurate, and that fields of the same type (such as City fields) are consistently defined throughout the database.

Page 42 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Domain integrity is enforced using: ‰

Data Type and Length

‰

Default Values

‰

NULL Values

‰

Check constraint

Data Type and Length By specifying the data type and maximum length for each column when a table is created, the DBMS will automatically ensure that only the correct type of data with the maximum length allowed is stored in that column.

Default Values When columns are created within tables, they can be assigned a default value that will be used when inserting or loading the data which do not provide an explicit value for that column. Each column can have only one default value. User can provide a default value for a column. If there is no user specific default value, DB2 will assign the default value based on the data type of that column. DB2 Data Types with Default Values: Data Type

COBOL PIC

COBOL USAGE

Default

Description

CHAR(n)

PIC X(n)

DISPLAY

Blanks

Fixed length character (EBCDIC) data

VARCHAR(n)

PIC X(n)

DISPLAY

Empty String

Variable length character data

SMALLINT

PIC S9(4)

COMP OR COMP-4

0

Half word integer data

INTEGER

PIC S9(9)

COMP OR COMP-4

0

Full word integer data

DECIMAL(p,s)

PIC S9(p)V9(s)

COMP-3

0

Packed decimal data. p è number of decimal digits s è number of digits to the right side of the decimal point

DATE

PIC X(10)

DISPLAY

Current Date

Date data (yyyy-mm-dd)

TIME

PIC X(8)

DISPLAY

Current Time

Time data (hh.mm.ss)

TIMESTAMP

PIC X(26)

DISPLAY

Current timestamp

Date and Time data with microseconds (yyyy-mm-ddhh.mm.ss.mmmmmm)

GRAPHIC

PIC G(n)

DISPLAY-1

Blanks

Double byte character set (DBCS) data

VARGRAPHIC

PIC G(n)

DISPLAY-1

Empty String

Variable length DBCS data

FLOAT(n)

None

COMP-1 or COMP-2

0

Floating point data in single or double precision format

Page 43 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 NULL Values: Whenever a value is missing or unknown, it is said to be Null. A null value represents neither zero (in the case of numeric data) nor blank (represented by one or more spaces in the case of textual data). Zero and blank are actual values and can be meaningful in some way under certain circumstances. For example, a zero can represent the current state of an Account Balance; a blank in a Middle Initial field can represent the fact that an employee has no middle initial in his or her name. In the following figure, a blank represents the fact that Washington, D.C., is not located in any county whatsoever.

A null value is typically used to represent an unknown value in a field. In the above figure, for example, there are null values in the County field. Shannon McLain did not know what county she lived in at the time her data was entered into the database, so no entry was made into the County field. As a result, the County field contains a null value. This value can be changed, however, once Shannon finds out what county she lives in. A null value is also used to represent a missing value in a field. If the person who entered the data for Shannon McLain failed to ask her for the name of the county she lives in, the data is considered missing since no entry was made into the County field due to operator error. Once the error is recognized, it can be easily corrected by obtaining the appropriate value from Ms. McLain.

A drawback to null values is that they cannot be evaluated by mathematical expressions or aggregate functions. If a null value is used in a mathematical expression, that expression will evaluate to Null. In figure Products, Total Value is derived from the mathematical expression "[SRP] * [Qty On Hand]." Note, however, that the value for the Total Value field is missing where the Qty On Hand value is Null, resulting in a null value for the Total Value field as well. This is

Page 44 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 logically reasonable—if the number is unknown, the value will necessarily be unknown. Also there is a serious undetected error that occurs if all the values in the Total Value field are then added together: an inaccurate total. The only way to obtain an accurate total is to provide a value for the entries in the Qty On Hand field that are currently Null. The result of an aggregate function, such as "Count()," will be Null if it is based on a field that contains null values. For example, the following figure shows the results of a summary query that counts the total number of occurrences of each category in the PRODUCTS table shown above. The value of Total Occurrences in the summary query is the result of the function expression "Count([Total Occurrences])." Notice that the summary query shows 0 occurrences of an unspecified Category, implying that each product has been assigned a category. This information is clearly inaccurate because there are two products in the PRODUCTS table that have not been assigned a category.

Check Constraint A check constraint is a rule that specifies the values that are allowed in one or more columns of every row of a table. Check constraint enforces business rules directly into the database without requiring additional application logic. This can be defined during column definition.

Summary ‰

Data Integrity ensures the accuracy of the data in a database.

‰

Types of Data Integrity o o o

Entity Integrity Referential Integrity Domain Integrity

‰

Entity integrity enforces each occurrence of an entity must be uniquely identifiable and is achieved through primary key.

‰

A table definition can be complete only when a unique index is created on its primary key.

‰

Unique constraint also behaves similar to primary key constraint except the fact of the number of unique constraints can be more than one in a table.

‰

Unique index column allows null values and does not support RI as against primary or unique constraint column.

‰

Foreign key is a column in a child table which holds the value of primary key column of a parent table.

‰

Referential integrity (RI) ensures each row in a dependent table must have a foreign key that is equal to a primary key in the parent table.

‰

Rules to ensure Referential integrity:

Page 45 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Operation Insert

Child Table

Parent Table

Allowed as long as the primary key value Allowed if the foreign key value matches the value of Primary key is unique. of the parent table.

Update

Allowed if there are no foreign key Allowed if the foreign key value matches the value of Primary key references in the child tables. of the parent table.

Delete

Allowed.

‰

Depending upon the action specified during table definition. Restrict: Not allowed if there are any foreign key references Cascade: Allowed and deletes the foreign key references if any in the child tables. SET TO NULL: Allowed and a Null value will be set in the foreign key references of the child tables

Domain integrity ensures the possible values of a column and is achieved through: o Data Type and Length: o Commonly used DB2 data types: Char, Varchar, Smallint, Integer, Decimal, Date, Time, Timestamp o Default Values:

o

Can be user defined or depends on the data type Used for columns with the missing values during insertion NULL Values: Unknown or missing value

o

Check constraint: Enforces business rules and allows only the predefined values

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

What is data integrity? What is entity integrity and how do you achieve it? Can you create a table without a primary key? Can a primary key column hold a value of null? State the importance of unique index in the primary key. What is a unique constraint? Differentiate between the primary key constraint and unique constraint. State the differences between primary key index and unique index. What is a foreign key? What is a referential integrity? List the rules applied to ensure RI while inserting, updating, and deleting the data both in the parent table as well as in the child table. What is domain integrity and how to achieve it? State the different DB2 data types. What is Null? What is check constraint?

Page 46 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 08: Interaction with DB2 Learning Objectives After completing the session, you will be able to: ‰

Access DB2 data using DB2I, SPUFI and QMF

Interaction with DB2: Overview An environment is connected to a DB2 subsystem by an attachment facility. Whenever there is a need of interaction with DB2, a thread will be established. A thread is a control structure used to: ‰

Send requests to DB2

‰

Send data from DB2 to the requestor

‰

Communicate the status of each SQL statement after it is executed

TSO as a Door to DB2: You use TSO (Time-Sharing Option) environment as a door that provides access to DB2 data. The TSO Attachment Facility provides access to DB2 resources in two ways: ‰

Online mode, in the TSO foreground, using ISPF (Interactive System Productivity Facility) panels

‰

Batch mode using the TSO Terminal Monitor Program - IKJEFT01 (or IKJEFT1B)

Common types of TSO foreground users include: ‰

DB2I

‰

QMF

Page 47 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 DB2I DB2I (DB2 Interactive) is a TSO-based DB2 application. It consists of a series of ISPF panels, programs, and CLISTs enabling rapid access to DB2 services and data. DB2I increases the TSO DB2 developer's productivity.

How to access DB2I: ‰

Log on to TSO as you normally would. The ISPF main menu appears.

‰

Choose Option 8 (DB2 - Perform DATABASE 2 Interactive Functions) in Cognizant Mainframe.

‰

DB2I Main menu appears as shown in the following screenshot.

DB2I Primary Option Menu

‰

Following Options are available with DB2I: o o o

o

o

o o

SPUFI: SQL Processor Using File Input. DCLGEN: Declaration Generator. PROGRAM PREPARATION: Prepares a program containing embedded SQL for execution. PRECOMPILE: Program containing embedded SQL is parsed to retrieve all SQL and replace it with calls to a runtime interface to DB2 BIND/REBIND/FREE: Provides the capability to bind a DB2 plan & package, rebound a plan & package, remove plan & package from the system RUN: enables to run a DB2 application program DB2 COMMANDS: Enables to submit DB2 commands using TSO.

Page 48 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

o

UTILITIES: Provides panels that ease the administrative burdens of DB2 utility processing DB2I DEFAULTS:

o

Lets you modify parameters that control the operation of DB2I Be sure that the proper DB2 subsystem is specified in the “DB2 Name” parameter Be sure that the proper language to be used for preparing DB2 programs in the “Application Language” parameter A valid job card needs to be supplied in the “DB2I Job Statement” parameter. EXIT: Leaves DB2I

o

SPUFI The first option in the DB2I main menu is SPUFI (SQL Processor Using File Input). SPUFI is intended primarily for application programmers who wish to test the SQL portions of their programs or administrators who wish to perform SQL operations. SPUFI reads SQL statements contained as text in a sequential file or in a member of a PDS, processes those statements and places the results in an ISPF browse session. By specifying the input and output data sets and selecting the appropriate options, we can execute SQL statements in an online mode. The SPUFI Panel is as follows.

Input Dataset

Output Dataset

Other Options

Page 49 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

You need to enter Input data set name and Output data set name

Input Data Set Input dataset must be allocated before invoking SPUFI. This can be a member of Partitioned Data Set or a Sequential Data Set. This can be empty and can be edited as part of the SPUFI session. It is recommended to maintain a partitioned data set to keep track of SQL statements used. Input dataset can be defined as a fixed, blocked data set with an LRECL of 80. SQL statements can be written in all but the last 8 bytes of each input record; this area is reserved for sequence numbers. This can contain multiple SQL statements, as long as they are separated by semicolons. Comments are preceded by two hyphens. If the input file contains multiple SQL statements, SPUFI will stop execution of those statements as soon as it encounters an error in any one of them. Sample SQL statements in the input data set as follows: --DELETE FROM THYD001.TEST --WHERE TEST_NO = 'A114'; -SELECT * FROM THYD001.TEST; --

Output Data Set The output data set need not be allocated before using SPUFI. If the output data set does not exist, SPUFI creates a virtual, blocked sequential data set with an LRECL of 4092. The output file will contain a sequence of results, one for each statement (including the relevant SQLCODE), followed by a summary of the overall execution (including, in particular, an indication as to which of Commit and Roll Back occurred). There are some specific defaults to be set for Output data set.

Page 50 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 When the SQL is executed and browsed, an output data set like the following appears:

Query

Query Result

Information about the Query Result

Page 51 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Other Options: After entering Input data set name and Output data set name, we need to specify following options. ‰

CHANGE DEFAULTS: When Y is specified, the SPUFI defaults panel appears as follows:

Isolation Level

‰

Options of “CURRENT SPUFI DEFAULTS”:

o

Typically, defaults are changed only once—the first time someone uses SPUFI. ISPF saves the defaults entered from session to session. Be sure to specify the following defaults:

o

Isolation Level: Always set this option to CS (Cursor Stability). (Note: You will study about Isolation Level in detail in your forthcoming sessions.) Max Select Lines: Set to an appropriate number. If we will be selecting from large tables that return more than 250 rows, the installation default value of 250 is insufficient. SPUFI stops returning rows after reaching the specified limit, and it issues a message indicating so. All the remaining installation defaults are appropriate. So keep them as they are.

o

EXECUTE: When Y is specified, the SQL in the input file is read and executed.

o

Page 52 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 o

o

AUTOCOMMIT: When Y is specified, a COMMIT is issued automatically after the successful execution of the SQL in the input file. When you specify N, SPUFI prompts you about whether a COMMIT should be issued. If the COMMIT is not issued, all changes are rolled back. Note: You will study about commit and rollback in our forthcoming sessions. BROWSE OUTPUT: When Y is specified, SPUFI places you in an ISPF browse session for the output data set. You can view the results of the SQL that was executed.

Note: Specifying Y for all these options (from 6 to 9) except Change Defaults (5) is common.

QMF QMF (Query Management Facility) is an interactive query tool used to produce formatted query output. It is similar to SPUFI but has much more advanced features to produce formatted output. In Cognizant mainframe, choose the option “TS.QMF” in the ISPF main menu; you will get the QMF Home Panel as follows:

Options

Command Line

Notice the numbered options in the bottom portion of the screen. These numbers correspond to QMF functions:

Page 53 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 There are three basic QMF objects to produce formatted reports of DB2 data: ‰

Queries

‰

Forms

‰

Procs

Queries You will see how to produce a simple report: ‰

Press F6 to navigate to the QMF Query panel, which is initially blank.

‰

Type the following statement at the COMMAND prompt and press Enter DRAW

‰

Following panel will appear:

Query

Options

Page 54 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

To run this query, press F2 which will produce this report.

Query Result as Report

‰

You can save a query by typing the following in the Command prompt SAVE AS

‰

Press F4 to print the report.

‰

You can format this report using Forms by pressing F9.

Page 55 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Forms ‰

Forms are used to format the report of the query output.

‰

Press F9 to go to a Form.

‰

A default form is generated for each query when it is run.

‰

QMF Forms enable us to perform the following: o Code a different column heading o Specify control breaks o Code control-break heading and footing text o Specify edit codes to transform column data (for example, suppress leading zeroes or display a currency symbol) o Compute averages, percentages, standard deviations, and totals for specific columns o Display summary results across a row, suppressing the supporting detail rows o Omit columns in the query from the report

QMF Form Panel is as follows:

Form Panel

Page 56 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Procs ‰

A QMF query can contain only one SQL statement in contrast with SPUFI, which can contain multiple SQL statements as long as they are separated by a semicolon.

‰

QMF Proc is used to execute multiple SQL statements at one time.

‰

QMF Procs contain QMF commands that are tied together and executed serially.

‰

By pressing F10, you can enter into PROC and can execute the queries as follows:

Proc Panel

Page 57 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Following is a typical QMF user's session. If you type a single SQL statement and press a few function keys, then an end-user report is generated.

Summary ‰

An environment is connected to DB2 by an attachment facility by establishing a thread.

‰

TSO interacts with DB2 through: o o

‰

The most common online mode includes: o o

‰

Online mode Batch mode DB2I QMF

DB2I (DB2 Interactive) is a TSO-based DB2 application, which increases the TSO DB2 developer's productivity.

Page 58 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

DB2I helps application programmers and administrators to: o o o o o

Run queries (SPUFI) Generate declare code (DCLGEN) Prepare programs (precompile, bind, rebind, free, run) Issue DB2 commands Prepare DB2 utilities for execution

‰

SPUFI supports the online execution of SQL statements from TSO terminal. o By specifying an input and output data set and selecting the appropriate options, you can execute SQL statements in an online mode.

‰

QMF (Query Management Facility) is an interactive query tool used to produce formatted query output. o

QMF objects to produce formatted reports of DB2 data are: Queries to execute a query to produce report Forms to format the query output (report) Procs to execute multiple queries to perform series of actions

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

What is an attachment facility? What is a thread? How does TSO interact with DB2? List the common TSO Online modes through which DB2 interaction happens. What is DB2I? List the different options in DB2I. What is SPUFI? Explain the different options in SPUFI. What is QMF? Explain the important functionalities available in QMF.

Page 59 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 09: SQL Learning Objectives After completing this session, you will be able to: ‰

Create the following objects: o Storage Group o Database o Table space

SQL: Overview SQL (Structured Query Language) is a language designed specifically for communicating with databases and is a powerful tool for manipulating data. It is the standard query language for relational database management systems (RDBMS). It is a database-independent language that allows you to query data and to perform CRUD (Create, Update, and Delete) operations. SQL is easy to learn. The statements are all made up of descriptive English words. SQL consists of three sublanguages as follows: ‰

DDL: Data Definition Language

‰

DML: Data Manipulation Language

‰

DCL: Data Control Language

Page 60 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

DDL DDL (Data Definition Language) creates and maintains physical data structures using the following statements. ‰

Create: Creating the objects.

‰

Alter: Changing the characteristics of the existing objects.

‰

Drop: Deleting the objects.

DDL – Create Storage Group Following syntax is used for creating storage group: CREATE STOGROUP VOLUMES () or VOLUMES (*) VCAT DATACLAS MGMTCLAS STORCLAS ‰

VOLUMES: Defines the volumes of the storage group.

‰

(*) indicates that SMS (Storage Management Subsystem) will manage the volumes to be used.

‰

VCAT: Identifies the integrated catalog facility catalog for the SG.

‰

DATACLAS: Identifies the name of the SMS data class to associate with the SG.

‰

MGMTCLAS: Identifies the name of the SMS management class to associate with SG.

‰

STORCLAS: Identifies the name of the SMS storage class to associate with the SG.

Example: Create a storage group, DSN8G910, of volumes ABC005 and DEF008. DSNCAT is the integrated catalog facility catalog name. CREATE STOGROUP DSN8G910 VOLUMES (ABC005,DEF008) VCAT DSNCAT;

DDL – Alter Storage Group Following syntax is used for altering the storage group. ALTER STOGROUP ADD VOLUMES() | REMOVE VOLUMES () DATACLAS MGMTCLAS STORCLAS

Page 61 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

ADD VOLUMES: Adds volumes to the storage group.

‰

REMOVE VOLUMES: Removes volumes from the storage group.

Example: Alter storage group DSN8G910. Add volumes DSNV04 and DSNV05. ALTER STOGROUP DSN8G910 ADD VOLUMES (DSNV04,DSNV05);

Try It Out Problem Statement: Alter storage group DSN8G910. Remove volumes DSNV04 and DSNV05. Code: ALTER STOGROUP DSN8G910 TO REMOVE VOLUMES (DSNV04,DSNV05);

DDL – Create Database Database creation syntax is as follows: CREATE DATABASE BUFFERPOOL INDEXBP STOGROUP CCSID // ‰

BUFFERPOOL: o

o ‰

Specifies the default buffer pool name to be used for table spaces created within the database. If you omit the BUFFERPOOL clause, then the default BP, BP0 is used.

INDEXBP: o

o

Specifies the default buffer pool name to be used for the indexes created within the database. If you omit the INDEXBP clause, the default BP, BP0 is used.

‰

STOGROUP: Specifies the storage group to be used to support DASD space requirements for table spaces and indexes within the database. The default is SYSDEFLT.

‰

CCSID (Coded Character Set ID) o o

Specifies the default encoding scheme for data stored in the database. Encoding Schemes are ASCII, EBCDIC, UNICODE.

Example: Create a database DSN8D91P. Specify DSN8G910 as the default storage group to be used for the table spaces and indexes in the database. Specify 8KB buffer pool BP8K1 as the default buffer pool to be used for table spaces in the database, and BP2 as the default buffer pool to be used for indexes in the database. CREATE DATABASE DSN8D91P STOGROUP DSN8G910

Page 62 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 BUFFERPOOL BP8K1 INDEXBP BP2;

Try It Out Problem Statement: Create a database DSN8TEMP. Use the defaults for the default storage group and default buffer pool names. Specify ASCII as the default encoding scheme for data stored in the database. Code: CREATE DATABASE DSN8TEMP CCSID ASCII;

DDL – Alter Database Database alteration syntax is as follows. ALTER DATABASE BUFFERPOOL INDEXBP STOGROUP CCSID Example: Change the default buffer pool for both table spaces and indexes within database ABCDE to BP2. ALTER DATABASE ABCDE BUFFERPOOL BP2 INDEXBP BP2;

DDL – Create Tablespace Table space creation syntax is as follows: CREATE TABLESPACE IN DEFINE LOGGED | NOT LOGGED TRACKMOD DSSIZE MAXPARTITIONS MEMBER CLUSTER NUMPARTS PARTITION BUFFERPOOL

Page 63 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 CCSID CLOSE COMPRESS LOCKMAX LOCKSIZE MAXROWS SEGSIZE : USING VCAT STOGROUP PRIQTY SECQTY ERASE : FREEPAGE PCTFREE : If you omit database-name, then the default DB, DSNDB04 is used. But it is advisable to specify the database. USING: ‰

VCAT: Specifies that the first data set for the table space is managed by the user, and following data sets, if needed, are also managed by the user.

‰

STOGROUP: Specifies the storage group in which the datasets for the table space will be defined and managed by DB2. o PRIQTY: Specifies the minimum primary space allocation for a DB2-managed data set. o SEQQTY: Specifies the minimum secondary space allocation for a DB2-managed data set. o ERASE: Indicates whether the DB2-managed data sets for the table space are to be erased when the corresponding table space is deleted. NO: It does not erase the data sets. This is the default. YES: Erases the data sets.

‰

FREEPAGE: o

o o ‰

PCTFREE: o

o o ‰

Specifies how often to leave a page of free space when the table space is loaded or reorganized. You must specify an integer in the range 0 to 255. If you specify 0, no pages are left as free space. Otherwise, one free page is left after every n pages, where n is the specified integer. Indicates what percentage of each page to be left as free space when the table space is loaded or reorganized. Integer can range from 0 to 99. The first record on each page is loaded without restriction. When additional records are loaded, at least integer percent of free space is left on each page.

DEFINE:

Page 64 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 o

o

o

‰

LOGGED: o

o ‰

Specifies at which point (when) the underlying data sets for the table space are physically created. YES: The data sets are created when the table space is created. This is the default. NO: The data sets are not created until data is inserted into the table space. DEFINE NO is applicable only for DB2-managed data sets (USING STOGROUP specification). DEFINE NO is ignored for user-managed data sets (USING VCAT specification). LOGGED: Specifies that changes that are made to the data in the specified table space are recorded in the log. NOT LOGGED: Specifies that changes that are made to data in the specified table space are not recorded in the log.

TRACKMOD: Specifies whether DB2 tracks modified pages in the space map pages of the table space. o o

YES: Tracked. This is the default. NO: Not tracked.

‰

DSSIZE: Specifies the maximum size for each data set.

‰

MAXPARTITIONS: Specifies the maximum number of partitions in a partitioned table space.

‰

MEMBER CLUSTER: Specifies that data inserted by an “insert operation” is not clustered by the clustering index. Instead, DB2 chooses where to locate the data in the table space based on available space.

Clustered and Non-Clustered Index: Indexes are organized with the B-Tree structure. ‰

Clustered Index: o The leaf level (the lowest level of the tree) is the data. o For a table that has a clustered index, the data is actually stored in the order of the index.

‰

Non-clustered Index: o o

‰

NUMPARTS: o o

‰

The leaf contains bookmarks to the actual data. The bookmarks in non-clustered indexes are in RID format (Row ID), that is, direct pointers to the physical location the row is stored in. Indicates that the table space is partitioned. Integer is the number of partitions.

PARTITION: o o

Specifies to which partition the subsequent using-block or free-block applies. Integer can range from 1 to the number of partitions given by NUMPARTS.

‰

BUFFERPOOL: Identifies the buffer pool to be used for the table space.

‰

CCSID: Specifies the encoding scheme for tables in the TS.

‰

CLOSE: When the limit on the number of open data sets is reached, specifies the priority in which data sets to be closed. o YES: Eligible for closing data sets. This is the default. o

NO: Eligible for closing after all CLOSE YES data sets is closed.

Page 65 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

COMPRESS: Specifies whether data compression applies to the rows of the table space. o YES: Specifies data compression. o NO: Specifies no data compression.

‰

LOCKMAX: Specifies the maximum number of page or row locks an application process can hold simultaneously in the table space.

‰

LOCKSIZE: Specifies the size of locks used within the table space.

‰

MAXROWS: Specifies the maximum number of rows that DB2 will consider placing on each data page.

‰

SEGSIZE: o o

Specifies that the table space will be a segmented. Integer specifies the number of pages that are to be assigned to each segment of the table space. Integer must be a multiple of 4 between 4 and 64 (inclusive).

Example: Create table space DSN8S91D in database DSN8D91A. Let DB2 define the data sets, using storage group DSN8G910. The primary space allocation is 52 kilobytes; the secondary, 20 kilobytes. The data sets need not be erased before they are deleted. Locking on tables in the space is to take place at the page level. Associate the table space with buffer pool BP1. The data sets can be closed when no one is using the table space. CREATE TABLESPACE DSN8S91D IN DSN8D91A USING STOGROUP DSN8G910 PRIQTY 52 SECQTY 20 ERASE NO LOCKSIZE PAGE BUFFERPOOL BP1 CLOSE YES;

Try It Out Problem Statement: Assume that a large query database application uses a tablespace to record historical sales data for marketing statistics. Create large tablespace SALESHX in database DSN8D91A for the application. Create it with 82 partitions, specifying that the data in partitions 80 through 82 is to be compressed. Let DB2 define the data sets for all the partitions in the tablespace, using storage group DSN8G910. For each data set, the primary space allocation is 4000 kilobytes, and the secondary space allocation is 130 kilobytes. Except for the data set for partition 82, the data sets do not need to be erased before they are deleted. Locking on the table is to take place at the page level. There can only be one table in a partitioned tablespace. Associate the tablespace with buffer pool BP1. The data sets cannot be closed when no one is using the tablespace. If there are no CLOSE YES data sets to close, then DB2 might close the CLOSE NO data sets when the DSMAX is reached.

Page 66 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Code: CREATE TABLESPACE SALESHX IN DSN8D91A USING STOGROUP DSN8G910 PRIQTY 4000 SECQTY 130 ERASE NO NUMPARTS 82 (PARTITION 80 COMPRESS YES, PARTITION 81 COMPRESS YES, PARTITION 82 COMPRESS YES ERASE YES) LOCKSIZE PAGE BUFFERPOOL BP1 CLOSE NO;

DDL – Alter Tablespace Table space alteration syntax is as follows: ALTER TABLESPACE [.] LOGGED | NOT LOGGED TRACKMOD BUFFERPOOL CCSID CLOSE COMPRESS LOCKMAX LOCKSIZE MAXROWS MAXPARTITIONS : USING VCAT STOGROUP PRIQTY SECQTY ERASE : FREEPAGE

Page 67 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 PCTFREE Example: Alter table space DSN8S91D in database DSN8D91A. BP2 is the buffer pool associated with the table space. PAGE is the level at which locking is to take place. ALTER TABLESPACE DSN8D91A.DSN8S91D BUFFERPOOL BP2 LOCKSIZE PAGE;

Summary ‰

SQL is the Structured Query Language, which is used for manipulating data for RDBMS.

‰

SQL consists of three sublanguages: o o o

‰

DDL (Data Definition Language) DML (Data Manipulation Language) DCL (Data Control Language)

DDL can do the following operations: o o o

Create Alter Drop Object

Operation

DDL

Storage Group

Creation

CREATE STOGROUP

Storage Group

Alteration

ALTER STOGROUP

Database

Creation

CREATE DATABASE

Database

Alteration

ALTER DATABASE

Tablespace

Creation

CREATE TABLESPACE

Tablespace

Alteration

ALTER TABLESPACE

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9.

What is SQL? List the sublanguages of SQL. List the operations to be performed under DDL, DML, and DCL. How do you create a storage group and explain the different options while creating? What are all the changes you can make while altering a storage group? How do you create a database and explain the different options while creating? What are all the changes you can make while altering a database? How do you create a tablespace and explain the different options while creating? What are all the changes you can make while altering a tablespace?

Page 68 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 10: SQL Learning Objectives After completing this session, you will be able to: ‰

Create the following objects: o

Table

o

Index

o

View

o

Alias

o

Synonym

DDL – Create Table Tables can be created in two ways: ‰

By specifying the columns and their data types explicitly.

‰

Creation based on the existing table.

Following is the table creation syntax by specifying the columns and their data types explicitly: CREATE TABLE : [WITH DEFAULT expression] [NULL|NOT NULL] [column-constraint-clause] [, [WITH DEFAULT expression] [NULL|NOT NULL] [columnconstraint-clause]...] (column-constraint-clause or table-constraint-clause) [CONSTRAINT ] [REFERENCES [()] [ON DELETE ] [UNIQUE] [PRIMARY KEY] [CHECK ()] IN .

Page 69 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

Default: o When a row is inserted into the table and no value is supplied for the column, the value specified in the default clause is inserted. o If the expression is missed in the default clause, then the system defined default value for the data type of the column will be substituted.

‰

NULL / NOT NULL:

‰

o

NULL is a default.

o

NOT NULL: Prevents the column from containing null values. Omission of NOT NULL implies that the column can contain null values.

Constraints: Constraints are defined on two possible levels. o

Column level:

o

A column-level constraint refers to a single column and is defined together with the column. These are also referred to as “inline constraints” Table level :

o ‰

Constraint-name: o o o

‰

o

The FOREIGN KEY constraint is defined with the REFERENCES keyword.

o

The FOREIGN KEY constraint (referential integrity constraint), ensures that the values in the foreign key correspond to values of a primary key. When defining a FOREIGN KEY constraint on a table, the column name does not have to be identical to the column name it references. By default the foreign key constraint is of type DELETE RESTRICT: Parent rows cannot be deleted if child rows exist. ON DELETE CASCADE: Allows the deletion of the primary key row and also deletes the foreign key rows that relate to it.

o

o

o

SET TO NULL: Allows the deletion of the primary key row and, instead of deleting all related foreign key rows, sets the foreign key columns to NULL.

UNIQUE constraint: o

To enforce unique values on an individual or a group of columns. UNIQUE constraint column should not contain NULL values.

o

A table can contain one or more UNIQUE constraints.

o

‰

Names the constraint and is optional. If a constraint name is not specified, then a unique constraint name is generated. If the name is specified, it must be different from the names of any referential, check, primary key, or unique key constraints previously specified on the table.

FOREIGN KEY constraint

o

‰

A table-level constraint references one or multiple columns and is defined separately after the definition of all the columns. These are called out-of-line constraints. You must use a table-level constraint if you are constraining more than one column.

PRIMARY KEY constraint: o

The PRIMARY KEY ensures all values in the column/columns are unique.

o

The clause must not be specified more than once and the identified columns must be defined as NOT NULL.

Page 70 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Note: If you do not create a unique index for a primary key or for a unique constraint, then an incomplete key is defined for the table, making the table inaccessible. ‰

Check: CHECK constraints enforce logical expressions on column/columns, which must evaluate to true for every row in the table.

Creating tables based on other tables. Following is the table creation syntax based on the exiting table: CREATE TABLE LIKE IN .

Try It Out Problem Statement: Create a table TB_TAB1 in database DB_DB1 and tablespace TS_TS1 with the following specifications with the column level constraints and with the implicit constraint names. Column Name

Data Type

TAB1_COL1

Integer

TAB1_COL2

Integer

TAB1_COL3

Varchar

TAB1_COL4

Date

TAB1_COL5

Char

TAB1_COL6

Integer

Length

Constraint

Remarks

Primary Key Not Null

5

foreign key to the ZIP column of the ZIPCODE table- if a row in the ZIPCODE table is deleted, any rows with the same zip code are to be deleted from the TAB1 table Current date should be inserted by default

20

Unique Should accept the values which are less than 100. Null value is allowed.

Code: CREATE TABLE TB_TAB1 (TAB1_COL1 INTEGER NOT NULL PRIMARY KEY, TAB1_COL2 INTEGER NOT NULL, TAB1_COL3 VARCHAR(5) REFERENCES ZIPCODE(ZIP) ON DELETE CASCADE, TAB1_COL4 DATE WITH DEFAULT, TAB1_COL5 CHAR(20) NOT NULL UNIQUE, TAB1_COL6 INTEGER CHECK(TAB1_COL6 < 100))

Page 71 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 IN DB_DB1.TS_TS1; How It Works: ‰

TAB1_COL1 INTEGER NOT NULL PRIMARY KEY: When you define a column as Primary Key, it should be defined with “Not Null” (The primary key column should not contain Null values).

‰

TAB1_COL5 CHAR (20) NOT NULL UNIQUE: When you define a column with the unique constraint, it should be defined with “Not Null” (The unique constraint column should not contain Null values).

‰

TAB1_COL4 DATE WITH DEFAULT: During insert if you do not provide a value for this column, then the default value of “Current Date” for the “Date” variable will be inserted.

Try It Out Problem Statement: Create a table TB_TAB1 in database DB_DB1 and tablespace TS_TS1 with the following specifications with the table level constraints by naming the constraints exclusively. Column Name

Data Type

TAB1_COL1

Integer

TAB1_COL2

Integer

TAB1_COL3

Varchar

TAB1_COL4

Date

TAB1_COL5

Char

TAB1_COL6

Integer

Length

Constraint

Remarks

Primary Key Not Null

5

foreign key to the ZIP column of the ZIPCODE table- if a row in the ZIPCODE table is deleted, any rows with the same zip code are to be deleted from the TAB1 table Current date should be inserted by default

20

Unique Should accept the values which are less than 100. Null value is allowed.

Page 72 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Code: CREATE TABLE TB_TAB1 (TAB1_COL1 INTEGER NOT NULL, TAB1_COL2 INTEGER NOT NULL, TAB1_COL3 VARCHAR(5), TAB1_COL4 DATE WITH DEFAULT, TAB1_COL5 CHAR(20) NOT NULL, TAB1_COL6 INTEGER NOT NULL, CONSTRAINT TAB1_COL1_PK PRIMARY KEY(TAB1_COL1), CONSTRAINT TAB1_COL3_FK FOREIGN KEY(TAB1_COL3) REFERENCES ZIPCODE(ZIP), CONSTRAINT TAB1_COL5_COL6_UK UNIQUE(TAB1_COL5,TAB1_COL6), CONSTRAINT TAB1_COL6_CK CHECK(TAB1_COL6 < 100)) IN DB_DB1.TS_TS1; How It Works: ‰

CONSTRAINT TAB1_COL5_COL6_UK UNIQUE(TAB1_COL5,TAB1_COL6): As the two columns TAB1_COL5 and TAB1_COL6 need to have unique constraints, you have combined and created this constraint and these two columns are defined with NOT NULL clause.

Try It Out Problem Statement: Create a table TB_TAB1 in a database DB_DB1 and in a table space TS_TS1, which exactly behaves like the table TB_TAB2. Code: CREATE TABLE TB_TAB1 LIKE TB_TAB2 IN DB_DB1.TS_TS1;

DDL – Alter Table Following is the table alteration syntax: ALTER TABLE [ADD ] [ALTER COLUMN ] [DROP CONSTRAINT | PRIMARY KEY| UNIQUE ( [,...])] [RENAME COLUMN TO ] [SET DATA TYPE ()]

Page 73 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 [SET ] [DROP DEFAULT]

Example: Column DEPT_NAME in table DSN8910.TB_DEPT was created as a VARCHAR(36).Increase its length to 50 bytes. Also, add the column DEPT_BLDG to the table DSN8910.TB_DEPT. Describe the new column as a character string column of length 3. ALTER TABLE DSN8910.TB_DEPT ALTER COLUMN DEPT_NAME SET DATA TYPE VARCHAR(50) ADD DEPT_BLDG CHAR(3);

Try It Out Problem Statement: Alter the TB_PRODINFO table to define a foreign key that references a non-primary unique key in the product version table (TB_PRODVER). The columns of the unique key are PRODVER_NAME and PRODVER_RELNO. Code: ALTER TABLE TB_PRODINFO FOREIGN KEY (PRODINFO_NAME, PRODINFO_VERNO) REFERENCES TB_PRODVER (PRODVER_NAME, PRODVER_RELNO) ON DELETE RESTRICT;

DDL – Create Index Following is the index creation syntax: CREATE [UNIQUE] INDEX ON ( [ASC | DESC]) [CLUSTER | NOT CLUSTER] [PARTITIONED] [PADDED | NOT PADDED] [] [] [DEFINE ] [COMPRESS ] [PARTITION BY RANGE ] [BUFFERPOOL ] [CLOSE ] [DEFER ] [PIECESIZE ]

Page 74 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 [COPY ] USING VCAT | STOGROUP PRIQTY SECQTY ERASE FREEPAGE PCTFREE PARTITION ENDING AT () ‰

UNIQUE: This prevents the table from containing two or more rows with the same value of the index key.

‰

ASC: o

o

Specifies that the index entries are to be kept in ascending order of the column values. This is the default setting.

‰

DESC: Specifies that index entries are to be kept in descending order of the column values.

‰

CLUSTER or NOT CLUSTER: Specifies whether the index is the clustering index for the table or not.

‰

PARTITIONED: Specifies that the index is data partitioned

‰

PADDED or NOT PADDED: Specifies how varying-length string columns are to be stored in the index. o PADDED: Specifies that varying-length string columns within the index are always padded with the default pad character to their maximum length. o NOT PADDED: Specifies that varying-length string columns are not to be padded to their maximum length in the index.

‰

Using clause: o

o

o

For non-partitioned indexes, the USING clause indicates whether the data sets for the index are to be managed by the user or managed by DB2. VCAT: Specifies that the first data set for the index is managed by the user, and that following data sets, if needed, are also managed by the user. STOGROUP: Specifies that DB2 will define and manage the index data sets. PRIQTY: Specifies the minimum primary space allocation for the DB2 managed data set. SECQTY: Specifies the minimum secondary space allocation for the DB2 managed data set. ERASE: Indicates whether the DB2-managed data sets are to be erased when the index is deleted.

‰

FREEPAGE: Specifies how often to leave a page of free space when index entries are created.

Page 75 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

PCTFREE: Determines the percentage of free space to be left in each non-leaf page and leaf page when entries are added to the index.

‰

DEFINE: Specifies when the underlying data sets for the index are physically created.

‰

‰

o

YES:

o

The data sets are created when the index is created YES is the default. NO: The data sets are not created until data is inserted into the index.

COMPRESS: Specifies whether compression for index data will be used. o

NO:

o

Specifies that no index compression will be used. This is the default. YES: Specifies that index compression will be used.

PARTITION BY RANGE: Specifies the index is the partitioning index. o

o

PARTITION integer: A PARTITION clause specifies the highest value of the index key in one partition of a partitioning index. ENDING AT: Specifies that this is the partitioning index and indicates how the data will be partitioned. CONSTANT: Specifies a constant value with a data type that must conform to the rules for assigning that value to the column. MAXVALUE: Specifies a value greater than the maximum value for the limit key of a partition boundary. MINVALUE: Specifies a value that is smaller than the minimum value for the limit key of a partition boundary.

‰

BUFFERPOOL: Identifies the buffer pool that is to be used for the index.

‰

CLOSE: Specifies whether or not the data set is eligible to be closed when the index is not being used and the limit on the number of open data sets is reached. o o

‰

YES: Eligible for closing. This is the default NO: Not eligible for closing.

DEFER: Indicates whether the index is built during the execution of the CREATE INDEX statement. o o

NO: The index is built. This is the default. YES: The index is not built.

‰

PIECESIZE: Specifies the maximum addressability of each data set for an index.

‰

COPY: Indicates whether the COPY utility is allowed for the index. o

NO:

o

Does not allows full image or concurrent copies NO is the default. YES: Allows full image or concurrent copies.

Example: 1. Create an index on the column TAB1_COL2 of a table TB_TAB1. CREATE INDEX IX_TAB1_COL2 ON TB_TAB1(TAB1_COL2);

Page 76 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 2. Create an index named IX_PROJECT_NAME on the TB_PROJECT table. The purpose of the index is to ensure that there are not two entries in the table with the same value for project name (PROJECT_NAME). The index entries are to be in ascending order. CREATE UNIQUE INDEX IX_PROJECT_NAME ON TB_PROJECT(PROJECT_NAME); 3. Create an index named IX_EMPLOYE_JOB_DEPT on the TB_EMPLOYE table. Arrange the index entries in ascending order by job title (EMPLOYE_JOB) within each department (EMPLOYE_DEPT). CREATE INDEX IX_EMPLOYE_JOB_DEPT ON TB_EMPLOYE

(EMPLOYE_DEPT, EMPLOYE_JOB);

Example: Create a unique index, named DSN8910.IX_DEPT, on table DSN8910.TB_DEPT. Index entries are to be in ascending order by the single column DEPT_NO. DB2 is to define the data sets for the index, using storage group DSN8G910. Each data set should hold 1 megabyte of data at most. Use 512 kilobytes as the primary space allocation for each data set and 64 kilobytes as the secondary space allocation. Make the index padded. The data sets can be closed when no one is using the index and do not need to be erased if the index is dropped. CREATE UNIQUE INDEX DSN8910.IX_DEPT ON DSN8910.TB_DEPT (DEPT_NO ASC) PADDED USING STOGROUP DSN8G910 PRIQTY 512 SECQTY 64 ERASE NO BUFFERPOOL BP1 CLOSE YES PIECESIZE 1M; Explanation: The underlying data sets for the index will be created immediately, which is the default (DEFINE YES). Assuming that table DSN8910.TB_DEPT is empty, if we wanted to defer the creation of the data sets until data is first inserted into the index, we would specify DEFINE NO instead of accepting the default behavior. Specifying PADDED ensures that the varying-length character string columns in the index are padded with blanks.

Page 77 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Example: Create a cluster index, named IX_EMP, on table TB_EMP in database DSN8910. Put the entries in ascending order by column EMP_NO. Let DB2 define the data sets for each partition using storage group DSN8G910. Make the primary space allocation be 36 kilobytes, and allow DB2 to use the default value for SECQTY. If the index is dropped, the data sets need not be erased. There are to be 4 partitions, with index entries divided among them as follows: Partition 1: entries up to H99 ‰

Partition 2: entries above H99 up to P99

‰

Partition 3: entries above P99 up to Z99

‰

Partition 4: entries above Z99

Associate the index with buffer pool BP1 and allow the data sets to be closed when no one is using the index. Enable the use of the COPY utility for full image or concurrent copies. CREATE INDEX DSN8910.IX_EMP ON DSN8910.TB_EMP (EMP_NO ASC) USING STOGROUP DSN8G910 PRIQTY 36 ERASE NO CLUSTER PARTITION BY RANGE (PARTITION 1 ENDING AT('H99'), PARTITION 2 ENDING AT('P99'), PARTITION 3 ENDING AT('Z99'), PARTITION 4 ENDING AT('999')) BUFFERPOOL BP1 CLOSE YES COPY YES;

DDL – Alter Index Following is the index alteration syntax. ALTER INDEX [REGENERATE] [ADD COLUMN ( ASC/DESC)] [CLUSTER | NOT CLUSTER] [PADDED | NOT PADDED] [] [] [COMPRESS ] [ALTER ]

Page 78 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 [BUFFERPOOL ] [CLOSE ] [PIECESIZE [COPY ] ‰

REGENERATE: Specifies that the index will be regenerated.

‰

ADD COLUMN: Adds column-name to the index.

‰

ALTER PARTITION: Identifies the partition of the index to be altered.

Example: 1. Alter the index DSN8910.IX_EMP. Indicate that DB2 is not to close the data sets that support the index when there are no current users of the index. ALTER INDEX DSN8910.IX_EMP CLOSE NO; 2. Alter partitioned index DSN8910.IX_DEPT. For partition 3, leave one page of free space for every 13 pages and 13 percent of free space per page. For partition 5, leave one page for every 25 pages and 25 percent of free space. For all the other partitions, leave one page of free space for every 6 pages and 11 percent of free space. ALTER INDEX DSN8910.IX_DEPT USING VCAT CATLGG FREEPAGE 6 PCTFREE 11 ALTER PARTITION 3 USING VCAT CATLGG FREEPAGE 13 PCTFREE 13, ALTER PARTITION 5 USING VCAT CATLGG FREEPAGE 25 PCTFREE 25;

Try It Out Problem Statement: 1. Alter the index DSN8910.IX_PROJ. Use BP1 as the buffer pool that is to be associated with the index, indicate that full image or concurrent copies on the index are allowed, and change the maximum size of each data set to 8 megabytes. 2. Assume that index IX_X1 contains a least one varying-length column and is a padded index. Alter the index to an index that is not padded.

Page 79 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Code: 1. ALTER INDEX DSN8910.IX_PROJ BUFFERPOOL BP1 COPY YES PIECESIZE 8M; 2. ALTER INDEX IX_X1 NOT PADDED;

DDL – Create View Following is the view creation syntax. CREATE VIEW AS Example: Create a view named VW_PROJECT upon the TB_PROJECT table that contains only those rows with a project number (PROJECT_NO) starting with the letters 'MA'. CREATE VIEW VW_PROJECT AS SELECT * FROM TB_PROJECT WHERE SUBSTR(PROJECT_NO, 1, 2) = 'MA'

DDL – Alter View Following is the view alteration syntax. ALTER VIEW REGENERATE ‰

You use the ALTER VIEW command to regenerate an invalid view after altering one of the base tables to ensure that the view continues to be valid.

DDL – Create Alias Following is the alias creation syntax. CREATE ALIAS FOR | Example: Create an alias for a table TB_TAB1. CREATE ALIAS AL_TAB1 FOR TB_TAB1;

DDL – Create Synonym Following is the synonym creation syntax. CREATE SYNONYM FOR . | .

Page 80 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Example: Create a synonym for a table DSN8910.TB_DEPT. CREATE SYNONYM SN_DEPT FOR DSN8910.TB_DEPT;

DDL – DROP The DROP statement removes an object in the current server. DATABASE: Whenever a database is dropped, all of its tablespaces, tables, index spaces, and indexes are also dropped. Tablespace: Whenever a tablespace is dropped, all the tables in the tablespace are also dropped. Table: Whenever a table is dropped, all referential constraints in which the table is a parent or dependent, and all synonyms, views, and indexes defined on the table are also dropped. If the table space for the table was implicitly created, it is also dropped. Alias is not dropped. DROP

STOGROUP DATABASE TABLESPACE TABLE INDEX VIEW ALIAS SYNONYM

Summary Object

Operation

DDL

Table

Creation

CREATE TABLE

Table

Alteration

ALTER TABLE

Index

Creation

CREATE INDEX

Index

Alteration

ALTER INDEX

View

Creation

CREATE VIEW

View

Alteration

ALTER VIEW

Alias

Creation

CREATE ALIAS

Synonym

Creation

CREATE SYNONYM

In order to delete the objects, you need to issue “DROP” command.

Page 81 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

List the different ways in which tables can be created. Describe how do you create a table and explain the options. Describe how do you alter a table and explain the options. Describe how do you create an index and explain the options. Describe how do you alter an index and explain the options. Describe how do you create a view and explain the options. What is the need of altering the view? How do you create an alias? How do you create a synonym? How can you delete the objects?

Exercises 1. Create a table PATIENT with the following characteristics: PATIENT_NO CHAR(4) LASTNAME VARCHAR(30) FIRSTNAME VARCHAR(30) GENDER CHAR(1) – Should accept only the values “M” & “F” DATE_OF_BIRTH DATE 2. Create a table PATIENT_ADDRESS with the following characteristics: PATIENT_NO CHAR(4) LINE_NO CHAR(1) ADDRESS VARCHAR(30) Primary key: PATIENT_NO,LINE_NO Foreign Key : PATIENT_NO (PATIENT Table)

Page 82 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 11: SQL Learning Objectives After completing this session, you will be able to: ‰

Perform the following DML (Data Manipulation Language) operations: o Insert o Update o Delete o Retrieval (Simple, multiple columns, all columns) o Sorting the retrieved data o Filtering the data o Concatenation o Using alias o Removing duplicates o Functions

DML – Insert The INSERT command adds new rows to a table or view. Inserting a row into a view also inserts the row into the table on which the view is based INSERT INTO / [()] VALUES () Example: The table TB_DEPT contains the following columns: ‰

DEPT_NO

‰

DEPT_NAME

‰

DEPT_MGR_NO

‰

DEPT_ADMR.

1. Insert a new department with the following specifications into the TB_DEPT table. ‰

Department number (DEPT_NO) is 'E31'

‰

Department name (DEPT_NAME) is 'ARCHITECTURE'

‰

Managed by (DEPT_MGR_NO) a person with number '00390'

‰

Reports to (DEPT_ADMR) department 'E01'.

INSERT INTO TB_DEPT VALUES (‘E31’ , ‘ARCHITECTURE’ , ‘00390’ , ‘E01’);

Page 83 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 2. Insert a new department into the TB_DEPT table as in example 1, but do not assign a manager to the new department. INSERT INTO TB_DEPT (DEPT_NO , DEPT_NAME , DEPT_ADMR ) VALUES (‘E31’ , ‘ARCHITECTURE’ , ‘E01’);

DML – Update The UPDATE statement updates the values of specified columns in the rows of a table or view. UPDATE / SET = WHERE Example: Change the manager (DEPT_MGR_NO) for the department (DEPT_NAME) ‘ARCHITECTURE’ to ‘00455’, in the table TB_DEPT. UPDATE TB_DEPT SET DEPT_MGR_NO = ‘00455’ WHERE DEPT_NAME = ‘ARCHITECTURE’ ;

DML – Delete The DELETE statement deletes rows from a table or view DELETE / WHERE Note: If there is no “where” clause in the Delete statement, then SQL will delete all the data in the table. So you need to be very careful while executing the Delete statement and make sure that there is a Where clause. Example: 1. Delete department (DEPT_NO) 'D11' from TB_DEPT table. DELETE FROM TB_DEPT WHERE DEPT_NO = ‘D11’; 2. Delete all the departments from TB_DEPT table (that is, empty the table). DELETE FROM TB_DEPT;

Page 84 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

DML – Simple Retrieval SELECT is used to retrieve table data To use SELECT, at a minimum, specify two pieces of information, that what you want to select and from where you want to select it. SELECT FROM Example: SELECT prod_name FROM tb_prod; This SELECT statement will retrieve a single column called prod_name from the table tb_prod.

DML – Retrieving Multiple Columns To retrieve multiple columns from a table, multiple column names must be specified after the SELECT keyword, and each column must be separated by a comma. Example: SELECT prod_id, prod_name, prod_price FROM tb_prod; This SELECT statement will retrieve data from multiple columns of the tb_prod table.

DML – Retrieving All Columns In addition to being able to specify desired columns (one or more, as seen earlier), SELECT statements can also request all columns without having to list them individually. This is done by using the asterisk (*) wildcard character in lieu of actual column names, as follows: Example: SELECT * FROM tb_prod;

DML – Sorting Retrieved data To explicitly sort data retrieved using a SELECT statement, the ORDER BY clause is used. SELECT FROM ORDER BY Example: SELECT prod_name FROM tb_prod ORDER BY prod_name; This statement sorts the data alphabetically in the ascending order by the prod_name column.

Page 85 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 DML – Sorting by Multiple Columns To sort by multiple columns, simply specify the column names separated by commas in the ORDER BY clause. Example: SELECT prod_id, prod_price, prod_name FROM tb_prod ORDER BY prod_price, prod_name; This code retrieves three columns and sorts the results by two of them, first by price and then by name.

DML – Sorting by Column Position ORDER BY also supports ordering specified by relative column position. Example: SELECT prod_id, prod_price, prod_name FROM tb_prod ORDER BY 2, 3; ORDER BY 2 means sort by the second column in the SELECT list, the prod_price column. ORDER BY 2, 3 means sort by prod_price and then by prod_name.

DML – Specifying Sort Direction Data sorting is not limited to ascending sort orders (from A to Z). Although this is the default sort order, the ORDER BY clause can also be used to sort in descending order (from Z to A). To sort by descending order, the keyword DESC must be specified. Example: SELECT prod_id, prod_price, prod_name FROM tb_prod ORDER BY prod_price DESC; This code sorts the products by price in descending order (most expensive first).

DML – Filtering Data Retrieving just the data you want, involves specifying search criteria, also known as a filter condition. Within a SELECT statement, data is filtered by specifying search criteria in the WHERE clause. Example: SELECT prod_name, prod_price FROM tb_prod WHERE prod_price = 3.49;

Page 86 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 This statement retrieves two columns from the tb_prod table, but instead of returning all rows, only rows with a prod_price value of 3.49 are returned

DML – WHERE Clause Operators SQL supports a whole range of conditional operators in the WHERE clause as listed. Operator

Description

=

Equality



Non-equality

!=

Non-equality

<

Less than



Greater than

>=

Greater than or equal to

!>

Not greater than

BETWEEN

Between two specified values including the specified start and end value

IS NULL

Is a NULL value

Example: ‰

To List all products that cost less than $10 SELECT prod_name, prod_price FROM tb_prod WHERE prod_price < 10;

‰

To List all products not made by vendor DLL01 SELECT vend_id, prod_name FROM tb_prod WHERE vend_id 'DLL01';

‰

To retrieve all products with a price between $5 and $10, including the specified start and end values. SELECT prod_name, prod_price FROM tb_prod WHERE prod_price BETWEEN 5 AND 10;

‰

To return a list of all products that have no price (price unknown) SELECT prod_name FROM tb_prod WHERE prod_price IS NULL;

Page 87 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 DML – Advanced Filtering For a greater degree of filter control, SQL lets you specify multiple WHERE clauses. Operator: A special keyword used to join or change clauses within a WHERE clause. This is also known as logical operators.

Using the AND Operator To filter by more than one column, we use the AND operator to append conditions to our WHERE clause. This is a keyword used in a WHERE clause to specify that only rows matching all the specified conditions should be retrieved. “AND” instructs the DB2 to return only rows that meet all the conditions specified. Example: SELECT prod_id, prod_price, prod_name FROM tb_prod WHERE vend_id = 'DLL01' AND prod_price = 10; If you do not use parentheses, you will not get desired output. Whenever you write WHERE clauses that use both AND and OR operators, use parentheses to explicitly group operators.

Page 88 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Using the IN Operator The IN operator is used to specify a range of conditions, any of which can be matched. Example: SELECT prod_name, prod_price FROM tb_prod WHERE vend_id IN ('DLL01','BRS01') ORDER BY prod_name; IN operator accomplishes the same goal as OR. But IN has the following advantages. ‰

For long lists of valid options, the IN operator syntax is far cleaner and easier to read.

‰

The order of evaluation is easier to manage.

‰

The biggest advantage of IN is that the IN operator can contain another SELECT statement.

Using the NOT Operator NOT is a keyword used in a WHERE clause to negate a condition. Example SELECT prod_name FROM tb_prod WHERE NOT vend_id = 'DLL01' This code lists the products made by all vendors except vendor DLL01.

DML – Wildcard Filtering Wildcards are special characters used to match parts of a value. To use wildcards in search clauses, the LIKE operator must be used. Wildcard searching can be used only with text fields (strings).

The Percent Sign (%) Wildcard Within a search string, % means match any number of occurrences of any character. Example: To find all products that start with the word Fish SELECT prod_id, prod_name FROM tb_prod WHERE prod_name LIKE 'Fish%‘;

Page 89 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

The Underscore (_) Wildcard The underscore is used just like %, but instead of matching multiple characters, the underscore matches just a single character. Example: To find all products that has two characters followed by “inch teddy bear” SELECT prod_id, prod_name FROM tb_prod WHERE prod_name LIKE '__ inch teddy bear ';

DML – Removing Duplicates SQL uses DISTINCT to remove duplicates from the result set. Example: For getting the unique Vendor Zip codes, you need to use the following query. SELECT DISTINCT vend_zipcode FROM tb_vend;

DML – Concatenating Fields Concatenation is joining values together (by appending them to each other) to form a single long value. In SQL SELECT statements, you can concatenate columns by using a special operator “||”. Example: SELECT vend_name || ' (' || vend_country || ')' FROM tb_vend ORDER BY vend_name; The result of this query is as follows. ---------------------------------------------------------Bear Emporium (USA ) Bears R Us (USA ) Doll House Inc.

(USA )

DML – Using Aliases An alias is just that, an alternative name for a field or value. Aliases are assigned with the AS keyword. Example: SELECT vend_name || ' (' || vend_country || ')' AS vend_title FROM tb_vend; The result of this query is as follows.

Page 90 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 vend_title ---------------------------------------------------Bear Emporium (USA) Bears R Us (USA) Doll House Inc.

(USA)

DML – Performing Mathematical Calculations SQL Mathematical Operators are as follows: Operator

Description

+

Addition

-

Subtraction

*

Multiplication

/

Division

Example: SELECT order_id, order_quantity, order_item_price, order_quantity*order_item_price AS expanded_price FROM tb_order WHERE order_num = 20008;

DML – Functions Types of Functions are as follows: ‰

Aggregate function

‰

Text function

‰

Date and time functions

‰

Numeric functions

DML – Aggregate Functions Aggregate Functions are functions that operate on a set of rows to calculate and return a single value. It is often necessary to summarize data without actually retrieving it all, and SQL provides special functions for this purpose. Examples of this type of retrieval are: ‰

Determining the number of rows in a table

‰

Obtaining the sum of a set of rows in a table.

‰

Finding the highest, lowest, and average values in a table column.

Page 91 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Following is the list of Aggregate Functions: Function

Description

AVG()

Returns a column's average value

COUNT()

Returns the number of rows in a column

MAX()

Returns a column's highest value

MIN()

Returns a column's lowest value

SUM()

Returns the sum of a column's values

Example: SELECT AVG(prod_price) AS avg_price FROM tb_prod;

DML – Text Functions Following is the list of commonly used Text-Manipulation Functions: Function

Description

Example

LEFT()

Returns characters from left of string

LEFT(cust_firstname, 4)

LENGTH()

Returns the actual length of a string

LENGTH(cust_firstname)

LOWER()

Converts string to lowercase

LOWER(cust_firstname)

LTRIM()

Trims white space from left of string

LTRIM(cust_firstname)

RIGHT()

Returns characters from right of string

RIGHT(cust_firstname)

RTRIM()

Trims white space from right of string

RTRIM(cust_firstname)

UPPER()

Converts string to uppercase

UPPER(cust_firstname)

SUBSTR()

Returns a substring of a string. 2nd argument – starting position 3rd argument – length

SUBSTR(cust_firstname,3,4)

Returns the hexadecimal representation of its argument

HEX(cust_firstname)

HEX()

DML – Date and Time Manipulation Functions Following is the list of commonly used Date and Time Manipulation Functions: Function

Description

Example

CHAR

Returns a string representation of its first argument.

DAYS

Returns an integer representation of its argument.

DAYS(‘2008-01-01’)

YEAR

Returns the year part of its argument

YEAR(cust_hiredate)

MONTH

Returns the month part of its argument

MONTH(cust_hiredate)

CHAR(cust_hiredate,USA)

DAY

Returns the day part of its argument

DAY(cust_hiredate)

HOUR

Returns the hour part of its argument

HOUR(CURRENT TIME)

Page 92 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Function

Description

Example

MINUTE

Returns the minute part of its argument

MINUTE(CURRENT TIME)

SECOND

Returns the seconds part of its argument

SECOND(CURRENT TIME)

Returns the microsecond part of its argument

MICROSECOND(CURRENT TIMESTAMP)

DATE

Returns the date derived from its argument

DATE(‘2008-01-01’)

TIME

Returns the time derived from its argument

TIME(’13:00:00’)

MICROSECOND

TIMESTAMP

Returns the timestamp derived from its argument

TIMESTAMP(CURRENT DATE)

DML – Numeric Functions Following is the list of commonly used numeric functions: Function

Description

Example

DECIMAL

Returns a decimal representation of its argument

DECIMAL(inv_total, 10,3)

DIGITS

Returns a character string representation of its argument

DIGITS(inv_total)

FLOAT

Returns a floating point representation

FLOAT(cust_salary)

INTEGER

Returns an integer representation

INTEGER(cust_salary+.5)

ABS()

Returns a number's absolute value

ABS(inv_total)

COS()

Returns the trigonometric cosine of a specified angle

COS(inv_total)

EXP()

Returns the exponential value of a specific number

EXP(inv_total)

PI()

Returns the value of PI

PI(inv_total)

SIN()

Returns the trigonometric sine of a specified angle

SIN(inv_total)

SQRT()

Returns the square root of a specified number

TAN()

Returns the trigonometric tangent of a specified angle

SQRT(inv_total) TAN(inv_total)

Summary ‰

Types of DML functions are as follows: o Aggregate function o Text function o Date and time functions o Numeric functions

Page 93 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 o

Clause

Description

INSERT

Populate the data into table or view

UPDATE

Update the data in the table or view

DELETE

Delete the data from table or view

SELECT

Columns or expressions to be returned

FROM

Table to retrieve data from

WHERE

Row-level filtering

ORDER BY

Sort the data retrieved

DISTINCT

Remove duplicates

Test Your Understanding 1. 2. 3. 4. 5. 6. 7. 8. 9.

How do you insert the data into a table or view? How do you update the data in a table or view? How do you delete the data from the table or view? How do you retrieve multiple column values from the table? How do you retrieve all the column values from the table? How do you sort the retrieved data? How do you filter the data retrieved? What are the different WHERE clause operators? Explain about the logical operators in the WHERE clause.

10. 11. 12. 13. 14.

How do you match parts of the value? How do you remove duplicates? How do you concatenate fields? What are the mathematical operators? Explain different types of functions.

Exercises 1. Insert the following rows into the table PATIENT. PATIENT_NO

LASTNAME

FIRSTNAME

GENDER

DATE_OF_BIRTH

A111

HAR

BHU

F

1975-07-27

A112

MAHESH

LATHA

F

1980-08-17

A113

SWAMI

VIGNESH

M

1985-01-07

A114

RAM

PRABHU

M

1981-04-27

A115

KRISHNA

DHILIP

M

1969-04-14

A116

KANNAN

LEKHA

F

1980-05-18

A117

VENKAT

DEEPA

F

1977-02-21

A118

SWAMI

AKILA

F

1960-08-29

A119

GOPI

KANNAN

M

1965-05-17

A120

MS

GEETHA

F

1975-08-27

Page 94 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

2. 3. 4. 5.

Get gender and date of birth of patients. Count the number of patients. Get last names and first names of all patients whose last name starts with a letter 'M'. Get last names and first names of all patients whose last name starts with a letter 'M' and whose last name has only 2 characters. 6. Get Female patients only ordered by date of birth. 7. Get last name and first names of all patients who were born: ‰

before 1st January 1960

‰

after 31st December 1975

‰

between 1st January 1959 and the 31st December 1975

8. Add following rows to PATIENT_ADDRESS table. PATIENT_NO

LINE_NO

ADDRESS

A111

1

G3

A111

2

KONDAPUR

A111

3

HYDERABAD

A112

1

A12G3

A112

2

KUKATPALLY

A112

3

HYDERABAD

A113

1

G3

A113

2

NUNGAMBAKKAM

A113

3

CHENNAI

A114

1

A14G3

A114

2

KK NAGAR

A114

3

CHENNAI

A115

1

G3

A115

2

KORAMANGALA

A115

3

BANGALORE

Page 95 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 12: SQL Learning Objectives After completing this session, you will be able to: ‰

Perform the following DML operations: o Grouping o Subquery o Join o Union o DCL ƒ ƒ

Grant Revoke

DML – Grouping Data Grouping lets you divide data into logical sets so that you can perform aggregate calculations on each group. Groups are created using the GROUP BY clause in the SELECT statement. The GROUP BY clause instructs the DB2 to group the data and then perform the aggregate on each group rather than on the entire result set. Example: SELECT prod_vend_id, COUNT(*) AS num_prods FROM tb_prod GROUP BY prod_vend_id; The result of this query is as follows. prod_vend_id num_prods ----------------------------BRS01 3 DLL01 4 FNG01

2

This statement specifies two columns, prod_vend_id, which contains the ID of a product's vendor, and num_prods, which is a calculated field (created using the COUNT(*) function). The GROUP BY clause instructs DB2 to sort the data and group it by vend_id. This causes num_prods to be calculated once per vend_id rather than once for the entire table

Page 96 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

DML – Filtering Groups In addition to being able to group data using GROUP BY, SQL also allows you to filter which groups to include and which to exclude. For example, you might want a list of all customers who have made at least two orders. To obtain this data you must filter based on the complete group, not on individual rows. HAVING is very similar to WHERE. The only difference is that WHERE filters rows and HAVING filters groups. WHERE filters before data is grouped and HAVING filters after data is grouped. Example: SELECT order_cust_id, COUNT(*) AS orders FROM tb_order GROUP BY order_cust_id HAVING COUNT(*) >= 2; SELECT prod_vend_id, COUNT(*) AS num_prods FROM tb_prod WHERE prod_price >= 4 GROUP BY prod_vend_id HAVING COUNT(*) >= 2;

DML – Grouping and Sorting ‰

To sort the output of GROUP BY, you need to use ORDER BY.

Example SELECT order_num, COUNT(*) AS items FROM tb_order GROUP BY order_num HAVING COUNT(*) >= 3 ORDER BY order_num; In this statement, GROUP BY clause is used to group the data by order number so that the COUNT(*) function can return the number of items in each order. The HAVING clause filters the data so that only orders with three or more items is returned. Finally, the output is sorted using the ORDER BY clause.

DML – Subquery Subqueries are used to combine different queries into one single statement. Subqueries are always processed starting with the innermost SELECT statement and working outward. Example: SELECT order_cust_id FROM tb_order WHERE order_num IN

Page 97 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 (SELECT order_item_num FROM tb_order_item WHERE order_item prod_id = 'RGAN01'); When the preceding SELECT statement is processed, the DBMS actually performs two operations. First it runs the subquery: SELECT order_item_num FROM tb_order_item WHERE order_item_prod_id = 'RGAN01' This query is called “Inner Query”. This query returns two order numbers 20007 and 20008. Those two values are then passed to the WHERE clause of the “outer query” in the comma-delimited format required by the IN operator. The outer query now becomes the following: SELECT order_cust_id FROM tb_order WHERE order_num IN (20007,20008) ‰

You can use subquery in a Simple Comparison:

‰

IN

‰

ANY

‰

SOME

‰

ALL

‰

EXIST

‰

If a subquery returns a single row, then the =, , =, or operator may be used for comparison with the subquery. If multiple records are returned, the IN, ANY, ALL or SOME operator must be used. With ANY or SOME, the condition must be true for any one of the values returned by the subquery. With ALL, the condition must be true for all of the values returned by the subquery.

Example: Subquery which uses ANY operator is as follows: SELECT cust_no FROM tb_cust WHERE cust_no = ANY (SELECT inv_cust_no FROM tb_inv WHERE inv_total > 200);

Page 98 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Types of subqueries There are two types of subqueries: ‰

Non-correlated subquery

‰

Correlated subquery

Non-correlated subquery: In the subquery if the inner query and the outer query work independently, then the subquery is called Non-correlated subquery. Correlated subquery: In correlated subquery, the inner query does not work independently of the outer query. In this, the inner query is performed once for each row of the outer query. To correlate the table in the inner query with the table in the outer query, you need to define an alias for the outer query and use it as a qualifier in the inner query. ‰

When you use the alias in this context, it is called “correlation name” and the connection it makes is called a “correlated reference”.

‰

A correlated subquery with the EXISTS keyword does not name any column because no data is transferred when you use EXISTS.

Example: SELECT cust_name FROM tb_cust A WHERE NOT EXISTS (SELECT * FROM tb_inv WHERE inv_cust = A.cust_no)

EXISTS Operator ‰

The EXISTS operator is used for correlated subqueries.

‰

It tests if the subquery returns at least one row.

‰

The EXISTS operator returns true or false, never unknown.

‰

Because EXISTS tests only if a row exists, the columns shown in the SELECT list of the subquery are irrelevant. Typically, you use a single character text literal such as '1' or 'X' or the keyword NULL.

Example: This is a correlated subquery displays instructors where the INSTRUCTOR_ID has a matching row in the SECTION table. The result shows the INSTRUCTOR_ID, INSTRUCTOR_FIRST_NAME column values of instructors assigned to at least one section. SELECT instructor_id, instructor_last_name FROM tb_instructor I WHERE EXISTS (SELECT 'X' FROM tb_section

Page 99 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 WHERE I.instructor_id = instructor_id) For every row of the INSTRUCTOR table, the outer query evaluates the inner query. It checks to see if the current row's INSTRUCTOR_ID value exists for the SECTION table's INSTRUCTOR_ID column. Only if a row with the appropriate value is found, the condition is true and the outer row is included in the result.

NOT EXIST Operator: The NOT EXISTS operator is the opposite of the EXISTS operator; it tests if a matching row cannot be found.

DML – Join A join is a mechanism used to associate tables within a SELECT statement. For creating a join, you must specify all the tables to be included and how they are related to each other. Example: SELECT vend_name, prod_name, prod_price FROM tb_vend, tb_prod WHERE tb_vend.vend_id = tb_prod.vend_id; The SELECT statement starts in the same way as all the statements you have looked at so far, by specifying the columns to be retrieved. The big difference here is that two of the specified columns (prod_name and prod_price) are in one table, whereas the other (vend_name) is in another table. Unlike all the prior SELECT statements, this one has two tables listed in the FROM clause, tb_vend and tb_prod. You must use the fully qualified column name (table and column separated by a period) whenever there is a possible ambiguity about which column you are referring to. In this case, you specify tb_vend.vend_id and tb_prod.vend_id.

Types of Joins There are two types of joins: ‰

Inner Join

‰

Outer Join

Inner Join Inner Joins or Equi Joins are joins which include only the rows where the values in the joined columns match.

Page 100 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 You can code inner joins either by Implicit Syntax or Explicit Syntax. Example for Implicit syntax: SELECT vend_name, prod_name, prod_price FROM tb_vend, tb_prod WHERE tb_vend.vend_id = tb_prod.vend_id; Example for Explicit syntax: SELECT vend_name, prod_name, prod_price FROM tb_vend INNER JOIN tb_prod ON tb_vend.vend_id = tb_prod.vend_id;

Outer Join Outer Joins keep unmatched rows from the tables. Types of Outer Joins: ‰

Left Outer Join

‰

Right Outer Join

‰

Full Outer Join Join

Keep unmatched rows from

Left Outer Join

The outer table

Right Outer Join

The inner table

Full Outer Join

Both the tables

A full outer join can use only equals (=) comparison operator, but left and right outer joins can use any of the comparison operators. Each unmatched row is joined with the null row. Example: The following SELECT statement is a simple inner join. It retrieves a list of all customers and their orders: SELECT cust_id, order_num FROM tb_cust INNER JOIN tb_order ON tb_cust.cust_id = tb_order.cust_id; To retrieve a list of all customers, including those who have placed no orders, you can use the following outer join: SELECT cust_id, order_num FROM tb_cust LEFT OUTER JOIN tb_order ON tb_cust.cust_id = tb_order.cust_id; Each unmatched row is joined with the null row.

Page 101 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Using Table Aliases To shorten the SQL syntax, you use aliases. Alias will enable multiple uses of the same table within a single SELECT statement. Example: SELECT cust_name, cust_contact FROM tb_cust C, tb_order O, tb_order_item OI WHERE C.cust_id = O.cust_id AND OI.order_num = O.order_num AND prod_id = 'RGAN01'; Whenever possible, use a join instead of a subquery because: ‰

It is usually easier to understand

‰

A join is more efficient because it makes better use of indexes

DML – Union Using UNION, multiple SELECT statements can be specified, and their results can be combined into a single result set. A UNION must be comprised of two or more SELECT statements, each separated by the keyword UNION. Each query in a UNION must contain the same columns, expressions or aggregate functions Column data types must be compatible Example: You need a report on all customers in Illinois, Indiana, and Michigan. You also want to include all “Fun4All” customers, regardless of state. SELECT cust_name, cust_contact, cust_email FROM tb_cust WHERE cust_state IN ('IL','IN','MI') UNION SELECT cust_name, cust_contact, cust_email FROM tb_cust WHERE cust_name = 'Fun4All';

Including or Eliminating Duplicate Rows The UNION automatically removes any duplicate rows from the query result set. If you want all occurrences of all matches returned, then you can use UNION ALL instead of UNION. Example: SELECT cust_name, cust_contact, cust_email FROM tb_cust

Page 102 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 WHERE cust_state IN ('IL','IN','MI') UNION ALL SELECT cust_name, cust_contact, cust_email FROM tb_cust WHERE cust_name = 'Fun4All';

DCL Data should always be protected from would-e thieves or casual browsers. At the same time data must be accessible to users who need access to it, and so DB2 provide administrators with mechanisms by which to grant or restrict access to data. Database Security is managed through the SQL GRANT and REVOKE statements.

DCL - GRANT Grants privileges to a user to access a DB2 object. Issued by one user to grant certain privileges on resources to another user The general command format is as follows. GRANT {privilege-list/All} [ON resource-type resource-list] {authorization-id-list/PUBLIC}

TO

[WITH GRANT OPTION]

Example: To grant SELECT privileges on the TB_EMPLOYE table to the user HERON GRANT SELECT ON EMPLOYEE TO USER HERON

DCL - REVOKE Used to take away a certain privilege from a user Only privileges previously granted can be revoked Can be issued only by the granter or by a SYSADM user REVOKE

{privilege-list/ALL} [ON resource-type resource-list] FROM

{authorization-id-list/ PUBLIC}

Example: To revoke the SELECT privilege on the EMPLOYEE table from the user HERON REVOKE SELECT ON EMPLOYEE FROM USER HERON

Page 103 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Summary ‰

Subquery is used to combine different queries.

‰

Joins are used to join different tables.

‰

It is always advisable to use joins over subqueries to avoid performance issues. Clause

Description

GROUP BY

Group specification

HAVING

Group-level filtering

UNION

Combine the results of the multiple select statements

GRANT

Privileges to a user to access a DB2 object

REVOKE

Take away a certain privilege from a user

Test Your Understanding 1. Explain about GROUP BY with HAVING clause. 2. 3. 4. 5. 6. 7. 8.

What is a subquery? List the operators used in the subquery. Explain the types of subquery. What is a join? Explain about the different types of joins. What is UNION operator? Differentiate between UNION and UNION ALL.

9. What is DCL? 10. Explain about GRANT statement. 11. Explain about REVOKE statement.

Exercises 1. Select last names, first names and addresses (with the address lines displayed correctly) of all patients who have their corresponding addresses in the database. The output should look as follows. LASTNAME

FIRSTNAME

ADDRESS

HAR

BHU

G3

HAR

BHU

HYDERABAD

HAR

BHU

KONDAPUR

MAHESH

LATHA

KUKATPALLY

MAHESH

LATHA

A12G3

MAHESH

LATHA

HYDERABAD

Page 104 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 2. Get the number of patients in each city. The result should look as follows ---------+---------+---------+---------+---------+--CITY NUMBER_OF_PATIENTS ---------+---------+---------+---------+---------+--3. Get the number of patients in the city where there is more than one patient. 4. Get the list of cities from which the patients have come. 5. Get the first name and the corresponding address of the patient. If there is no address available for the patient the report should show Null values against their names. 6. Get the youngest patient’s first name. 7. Get the first name of the youngest male & female patient with their gender and date of birth. 8. Get the patient number along with the City who resides in Hyderabad and Chennai. 9. Get the list of patient number only if all the patients are having their corresponding address. Even when one patient doesn’t have the address, the output report should be empty. 10. Get the list of patient number for all the patients who don’t have address. 11. Get the list of patient number from the patient and patient address table without removing the duplicate value of patient number. 12. The city name “BANGALORE” got changed to “BLR”. Reflect this change in the addresses of the patients. 13. Delete the patient whose patient number is “A115” from the database.

Page 105 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 21: Introduction to Simple COBOL DB2 Application Program Learning Objectives After completing this session, you will be able to: Write a simple COBOL DB2 application program

‰

Embedded SQL In order to access or modify the data in a DB2 database, as a first step, you need to include SQL statements within the COBOL program. These SQL statements which are being embedded in the COBOL program are referred as “Embedded SQL”. To make the system understand the concept that the SQL is a different language from the host language (COBOL) of the application program, you need to enclose all embedded SQL statements in an EXEC SQL block. Delimit the embedded SQL as follows. EXEC SQL put text of SQL statement here END-EXEC. ‰

You must code the EXEC SQL and END-EXEC delimiter clauses in your application program in column 12 through 72, whether they are in the Data Division or in the Procedure Division.

‰

You should not code the embedded SQL in a COPY member.

DCLGEN ‰

While executing the SQL statements in the embedded SQL, you need to move the data from the program to DB2 or/and from DB2 to the program. In order to receive the data that is returned for a row or hold the data to update or add a row to a table, we need to define a structure called “Host Structure”. Although we can code this structure by ourselves, it is easier to let DB2 develop it from the data definitions of the database.

‰

Deceleration Generator (DCLGEN) is the utility that comes with DB2 which generates the host structure for a table. The output of DCLGEN is stored as a member of a PDS (Partitioned Data Set).

‰

The output of DCLGEN has two parts: o First part is “Table Declaration”: This is the “SQL DECLARE TABLE” statement which names the table and defines each of its columns. o Second part is “Host Structure”: This contains the COBOL definition of the host variables which can be used for a table in the application program.

‰

When we use DCLGEN for creating the COBOL definitions for the host structure, we can be sure that the COBOL definitions correspond correctly to the DB2 data types. Although we are not required to declare DB2 tables in our application program, doing so is a good programming practice. So explicitly DECLARE all tables to be used by our application program.

Page 106 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

Include the DCLGEN output in the WORKING-STORAGE section in order to include table declaration and host structure. You need to use include command for including the DCLGEN output. This is similar to COPY command. This must be delimited by EXEC SQL and END-EXEC. You need to specify the DCLGEN member name in which you have created the DCLGEN output. EXEC SQL INCLUDE END-EXEC.

Options while creating DCLGEN ‰

Following is the list of options available while creating DCLGEN through DB2I: o

ACTION:

o

ADD: For new DCLGEN member REPLACE: For modifying the existing member COLUMN LABEL:

o

Tells DCLGEN whether to include labels that are declared on any columns of the table or view as comments in the data declarations. (The SQL statement LABEL creates column labels to use as supplements to column names.) YES: To include column labels. NO: To ignore column labels. This is the default. STRUCTURE NAME:

o

You can specify 01 level variable for the host structure. This is optional and if you do not specify, DCLGEN will create a system generated structure name. FIELD NAME PREFIX:

o

o

Specifies a prefix that DCLGEN uses to form field names in the output. For example, if you choose ABCDE, the field names generated are ABCDE1, ABCDE2, and so on. If you leave this field blank, then the field names are the same as the column names in the table or view. DELIMIT DBCS: Tells DCLGEN whether to delimit DBCS (Double Byte Character String) table names and column names in the table declaration. COLUMN SUFFIX: Tells DCLGEN whether to form field names by attaching the column name as a suffix to the value you specify in FIELD NAME PREFIX. For example, if you specify YES, the field name prefix is NEW, and the column name is EMPNO, the field name is NEWEMPNO. If you specify YES, you must also enter a value in FIELD NAME PREFIX.

o

o

INDICATOR VARS: Tells DCLGEN whether to generate an array of indicator variables for the host variable structure. RIGHT MARGIN: Specifies the break point for statement tokens that must be wrapped to one or more subsequent records.

Page 107 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

You will create a DCLGEN for a table TB_RATE in “THYD018.DCLGEN.COPYLIB(DRATE)”

‰

Go to DB2I and select Option 2 in DB2I Primary Option Menu as follows:

Option 2 for DCLGEN

Page 108 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

In DCLGEN menu, enter appropriate values to create the DCLGEN.

Table Name

Dataset in which DCLGEN is created

Page 109 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

Once appropriate values are entered here press enter, we’ll get the following message for the successful creation of DCLGEN.

Message for the successful creation of DCLGEN

‰

DCLGEN is created in “THYD018.DCLGEN.COPYLIB(DRATE)” as follows:

Example: ****************************************************************** * DCLGEN TABLE(TB_RATE) * * LIBRARY(THYD018.DCLGEN.COPYLIB(DRATE)) * * ACTION(REPLACE) * * LANGUAGE(COBOL) * * QUOTE * * ... IS THE DCLGEN COMMAND THAT MADE THE FOLLOWING STATEMENTS * ****************************************************************** EXEC SQL DECLARE TB_RATE TABLE ( RATE_CAT CHAR(1) NOT NULL, RATE_PER_HOUR INTEGER NOT NULL ) END-EXEC. ****************************************************************** * COBOL DECLARATION FOR TABLE TB_RATE * ****************************************************************** 01 DCLTB-RATE. 10 RATE-CAT

PIC X(1).

Page 110 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 10 RATE-PER-HOUR PIC S9(9) USAGE COMP. ****************************************************************** * THE NUMBER OF COLUMNS DESCRIBED BY THIS DECLARATION IS 2 * ******************************************************************

Host Variables ‰

An area of storage is allocated by the host language (COBOL) and referenced in an SQL statement and this area is called “Host Variable”. Host structure describes the rows in the table and the host variables are the fields that receive the data that is returned for a row or hold data to update or add a row to a table. We must define host variables in the DATA DIVISION of our program in the WORKING-STORAGE section or in the LINKAGE section. As we’ve seen before, this we’ve achieved by including DCLGEN output in the WORKING-STORAGE section.

‰

When you use host variables in SQL statements, prefix them with a colon (:). When the same variable is referenced by the COBOL program outside the embedded SQL, do not prefix the variable with a colon.

‰

You can use host variables in the following ways: o As output data areas in the INTO clause of the SELECT and FETCH statements o

As input data areas for the SET clause of the UPDATE statement

o

As input data areas for the VALUES clause of the INSERT statement

o

As search fields in the WHERE clause for SELECT, INSERT, UPDATE, and DELETE statements As literals in the SELECT list of a SELECT statement

o

Example: How to use host variables: EXEC SQL SELECT EMP_NO INTO :HOSTVAR-EMPNO FROM TB_EMP END-EXEC. EXEC SQL UPDATE TB_EMP SET EMP_SALARY = :HOSTVAR-SALARY WHERE EMP_NO = :HOSTVAR-EMPNO END-EXEC. EXEC SQL DELETE FROM TB_EMP WHERE EMP_DEPT = :HOSTVAR-DEPT END-EXEC. EXEC SQL

Page 111 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 INSERT INTO TB_DEPT (DEPT_NO) VALUES (:HOSTVAR-DEPTNO) END-EXEC.

SQLCA While executing the application program, we need the information of describing the success or failure of the execution of an embedded SQL statement. For this purpose, you must include a structure called SQLCA (SQL Communication Area) in each DB2 application program. You do so by coding the following statement in our WORKING-STORAGE section: EXEC SQL INCLUDE SQLCA END-EXEC. Following is the COBOL layout of the expanded SQLCA: 01 SQLCA. 05 SQLCAID PIC X(8). 05 SQLCABC PIC S9(9) COMPUTATIONAL. 05 SQLCODE PIC S9(9) COMPUTATIONAL. 05 SQLERRM. 49 SQLERRML PIC S9(4) COMPUTATIONAL. 49 SQLERRMC PIC X(70). 05 SQLERRP PIC X(8). 05 SQLERRD OCCURS 6 TIMES PIC S9(9) COMPUTATIONAL. 05 SQLWARN. 10 SQLWARN0 PIC X(1). 10 SQLWARN1 PIC X(1). 10 SQLWARN2 PIC X(1). 10 SQLWARN3 PIC X(1). 10 SQLWARN4 PIC X(1). 10 SQLWARN5 PIC X(1). 10 SQLWARN6 PIC X(1). 10 SQLWARN7 PIC X(1). 05 SQLEXT. 10 SQLWARN8 PIC X(1). 10 SQLWARN9 PIC X(1). 10 SQLWARNA PIC X(1). 10 SQLSTATE

PIC X(5).

Page 112 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

SQLCODE The field SQLCODE in SQLCA, contains the return code passed by DB2 to the application program. The return code provides information about the execution of the last SQL statement. SQLCODE Value Zero Positive +100 Negative

Meaning Statement successful Statement successful, but with some exceptional condition Row not found or end of data Statement failed and serious error detected

Try It Out Problem Statement: Write a COBOL DB2 application program, to get the hourly rate for a particular rate category supplied by the user. Code: IDENTIFICATION DIVISION. PROGRAM-ID. FIRSTCD. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. ****************************************************************** * VARIABLES FOR ERROR ROUTINE. ****************************************************************** 01 WS-ERROR-MESSAGE. 10 FILLER PIC X(12) VALUE 'SQLCODE IS: '. 10 WS-SQLCODE PIC -9(3). 10 FILLER PIC X(5) VALUE SPACES. 10 WS-TABLE PIC X(15) VALUE SPACES. 10 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * INCLUDE DCLGEN ****************************************************************** EXEC SQL INCLUDE DRATE END-EXEC. ****************************************************************** * INCLUDE SQLCA ****************************************************************** EXEC SQL INCLUDE SQLCA

Page 113 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 END-EXEC. LINKAGE SECTION. 01 PARM-VALUE. 05 PARM-LEN PIC S9(4) COMP. 05 PARM-TXT PIC X(4). ****************************************************************** * FIRST COBOL DB2 PROGRAM WHICH GIVES THE HOURLY RATE FOR A * PARTICULAR RATE CATEGORY SUPPLIED BY THE USER. ****************************************************************** PROCEDURE DIVISION USING PARM-VALUE. 0000-MAIN-PARA. MOVE PARM-TXT TO RATE-CAT. EXEC SQL SELECT RATE_CAT ,RATE_PER_HOUR INTO :RATE-CAT ,:RATE-PER-HOUR FROM TB_RATE WHERE RATE_CAT = :RATE-CAT END-EXEC. EVALUATE SQLCODE WHEN 0 PERFORM 1000-DISPLAY-RATE THRU 1000-EXIT WHEN +100 PERFORM 2000-ROW-NOT-FOUND THRU 2000-EXIT WHEN OTHER MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '0000-MAIN-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. STOP RUN. 1000-DISPLAY-RATE. DISPLAY '-----------------------------------------------'. DISPLAY 'RATE CATEGORY: ' RATE-CAT. DISPLAY 'RATE PER HOUR: ' RATE-PER-HOUR. DISPLAY '-----------------------------------------------'. 1000-EXIT. EXIT. 2000-ROW-NOT-FOUND. DISPLAY '------------------------------------------------'. DISPLAY 'ROW NOT FOUND FOR THE RATE CATEGORY: ' RATE-CAT.

Page 114 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 DISPLAY '------------------------------------------------'. 2000-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. 9999-EXIT. EXIT. Refer File Name: First_RatePerHour_Program_Session#21_Slide#12 to obtain soft copy of the program code

Summary While developing COBOL DB2 application program, you need to perform the following tasks: 1. Embed the SQL statements and delimit them with EXEC SQL and END-EXEC 2. Include DCLGEN output for the tables used in the program in the WORKING-STORAGE section, which: i. Explicitly declares the table ii. Defines the host structure 3. Include SQLCA in the WORKING-STORAGE section 4. Check SQLCODE field in SQLCA after executing an SQL statement

Test Your Understanding 1. 2. 3. 4. 5.

What is ESQL (Embedded SQL)? What is a DCLGEN? What is a host variable? What is SQLCA? What is SQLCODE?

Exercises Develop a COBOL-DB2 application program which accepts “Patient Number” and displays Patient Information as follows: Patient Number: Patient Name: Gender:

xxxx

Date of Birth:



Page 115 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Session 26: Program Preparation and Execution Learning Objectives After completing this session, you will be able to: ‰

Develop a COBOL DB2 application program

‰

Execute a COBOL DB2 application program

Steps involved in Program Preparation ‰

Following are the steps involved in preparing a COBOL-DB2 application program: o o o o

Precompilation Bind Compilation Link Edit

Need for Precompilation In early days, many companies had different machines for development and production. Development often took place on an older model machine and COBOL was the language of choice. The LOAD modules were moved onto a bigger production machine and companies rarely had a COBOL license on the production machine. So, DB2 had to allow development on one box with a COBOL compiler but without a DB2 subsystem and allow production runs on a different box with a DB2 subsystem but without a COBOL compiler. So programmers wrote COBOL programs and embed SQL and during compilation, to look for COBOL errors, they required a system to strip out the SQL, leaving only COBOL and that system is Precompiler.

Tasks of Precompiler ‰

Expansion of “INCLUDE”: If the delimiters are surrounded an INCLUDE statement, the Precompiler goes to the INCLUDE library named in the job control language data definition statement and pulls the included MEMBERNAME into the program. This function is the same as a COBOL COPY MEMBERNAME, but the timing is different. COBOL Copybooks get copied in at COMPILE time; DB2 INCLUDEs get copied in at precompile time.

‰

Syntax Check: If the delimiters surround an SQL statement, the precompiler does a very basic syntax check to make sure that the column and table names are valid. The Precompiler uses the top part of the DCLGEN (Table Declaration) to validate the SQL syntax. So Precompiler does not need DB2 to run.

‰

Splitting the Program: Most important task performed by the DB2 Precompiler is to split the program into two parts: a COBOL part and a DB2 part. All of the SQL that are embedded is stripped out of the program and put into its own partitioned data set member, called a DBRM (Data Base Request Module).

Page 116 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 A single program containing two languages, COBOL and SQL, goes into the DB2 Precompiler and two pieces come out. ‰

“Modified Source Code” which is the COBOL with all of the SQL commented out and replaced with the equivalent COBOL Calls.

‰

“DBRM” which contains only SQL

As the “Modified Source Code” and “DBRM” will take different paths to get the runtime executables, in order to identify the correct pair during execution, the precompiler attaches timestamp both in “Modified Source Code” and in “DBRM” and is called “Consistency Token”. Following figure shows the functionality of Precompiler:

In the JCL, the Precompilation step is as follows: //********************************************************************** //* DB2 PRECOMPILE THE COBOL PROGRAM * //********************************************************************** //DB2PCOMP EXEC PGM=DSNHPC, // PARM='HOST(IBMCOB),XREF,SOURCE,FLAG(I),APOST,NEWFUN(NO)' //STEPLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD //DBRMLIB DD DISP=SHR,DSN=&DBRMLIB(&LOADMEM) //SYSCIN DD DSN=&&DSNHOUT,DISP=(NEW,PASS,DELETE),UNIT=SYSDA, // SPACE=(800,(500,500)) //SYSLIB DD DISP=SHR,DSN=&INCLUDE // DD DISP=SHR,DSN=&COBCOPY //SYSPRINT DD SYSOUT=* //SYSTERM

DD

SYSOUT=*

Page 117 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 //SYSUDUMP DD //SYSUT1 DD //SYSUT2 DD

SYSOUT=* SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA

//SYSIN

DISP=SHR,DSN=&SOURCE(&MEMNAME)

‰

DD

In the JCL, for the Precompilation we need to provide the following items. o Input: SYSIN: COBOL-DB2 application program (member name with the PDS) SYSLIB: DCLGEN PDS name o

Output: DBRMLIB: DBRM member name with the PDS. SYSCIN: Modified source code. (Generally this has the temporary dataset which will be passed to the compilation step).

Bind Tasks of Bind Authorization Check: DB2 must make sure that the programmer has the BIND authority and the SQL authority to perform the requested SQL task. Syntax Check: BIND task is a bit redundant, like precompile, must also check the syntax of the SQL, but the BIND check is more sophisticated. BIND uses the DB2 CATALOG table information to make sure that the column names are valid, comparisons are numeric-to-numeric, and so on. Optimization: The most important BIND task is to come up with run-time instructions for the SQL in the DBRM. Each SQL statement is parsed and all of the possible methods for retrieving the desired columns and rows from the table are weighed, measured, and evaluated based on possible estimated I/O, CPU, and SORT overhead. After all that input (and more) is weighed and compared, the cheapest, most cost-effective access path is chosen, and the runtime instructions for that one path are created. This process of choosing the optimized access path is called “Optimization”. This is repeated for each SQL statement in the DBRM. These runtime instructions are stored in the “PLAN”.

Page 118 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Plan ‰

A plan is an executable module containing the access path logic produced by the DB2 optimizer. It can be composed of one or more DBRMs and packages.

‰

There are two ways of doing BIND: o Bind DBRMs into PLANs o Bind DBRMs into PACKAGEs o

Need of Package ‰

In the early releases of DB2, the DBRM was bound into a PLAN. This method worked just fine as long as the program was a standalone program that is, PGMA was bound to a PLANA. When PGMA needed to CALL PGMB, since only one PLAN could be named in an execute statement, the PLAN had to contain run-time instructions for both PGMA and PGMB. This problem was solved by having the BIND instruction for PLANA consists of a member list; the DBRMs for both PGMA and PGMB were listed as members and if PGMB called PGMC, then the three would be listed as members. Member lists got longer and longer.

‰

Drawbacks of having a very long list: o

o

o

While binding, authorization check, syntax check, optimized access path and the creation of run time instructions for the chosen path is carried out. If the PLAN contains one member, PGMA, this process should be quick. But if there are 500 DBRMs in the member list, the BIND could take hours. If one of the programs (PGMA) changes in the list of 500 programs, the changed program must be precompiled and precompile changes the consistency token and creates a new DBRM. That new DBRM must be bound into the PLAN. When the PLAN is bound, all 500 DBRMs (not just the modified PGMA) will be rebound. It could take hours to BIND a PLAN, even though 499 of the 500 programs haven't changed. The same case that is, you need to bind the entire list if a new program is added to the list or any existing program is removed from the list.

To overcome these disadvantages, package concept came into picture.

Page 119 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 Package A package is a single, bound DBRM with optimized access paths. By using packages, the table access logic is "packaged" at a lower level of granularity, at the program level. To execute a package, you must first include it in the package list of a plan. Packages are not directly executed—they are only indirectly executed when the plan in which they are contained executes.

Understanding Plan and Package more clearly ‰

To help differentiate between plans and packages, consider a grocery store analogy. o

o

Before going to the grocery store, you should prepare a shopping list. As you go through the aisles, when you find an item on your list, you place the item in your shopping cart. After you pay for the items at the check-out register, the clerk places your grocery items in a bag. You can think of the purchased items as DBRMs. The bag is the plan. You have multiple DBRMs (grocery items) in your plan (shopping bag). In a package environment, rather than actually removing the items from the shelf, you would mark on your shopping list the location of each item in the store. Upon checking out, you would give the list to the clerk at the counter. The clerk then would place the list in the bag—not the actual items. The plan (bag) contains a list pointing to the physical location of the packages (grocery items) that are still on the shelf. This approach is a good way to compare and contrast the two different environments.

Version When using packages, you can keep multiple versions of a single package that refer to different versions of the corresponding application program. We can specify a version as a parameter to the DB2 precompiler.

Advantage of Version ‰

The programmer can use a previous incarnation of a program without rebinding.

‰

Before the availability of packages, when programmers wanted to use an old version of a program, they were forced to rebind the program's plan using the correct DBRM. If the DBRM was unavailable, they had to repeat the entire program preparation process.

Advantages of Package ‰

Reduced bind time and bind overhead: When you are utilizing packages and the SQL within a program changes, only the package for that particular program needs to be rebound. If packages are not used when multiple DBRMs are bound into a plan and the SQL within one of those programs changes, the entire plan must be rebound.

‰

Granularity of bind parameters: With packages, you can specify our bind options at the program level, such as the isolation level and release parameters. By specifying different parameters for specific packages and including these packages into a plan, many combinations of isolation level and release are possible. For example, create a single plan that provides an isolation level of cursor stability (CS) for one of its packages and an isolation level of repeatable read (RR) for another package. This combination of strategies is not possible in a plan-only environment.

Page 120 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ‰

Versioning: Packages can be versioned, thus enabling us to have multiple versions of the same package existing at the same time. Simply by running the appropriate load module, DB2 chooses the correct package to execute. DB2 uses a package selection algorithm to execute the correct access path.

Collection A collection is a user-defined name from 1 to 18 characters that the programmer must specify for every package. A collection is not an actual, physical database object.

Advantages of Collection ‰

By specifying a different collection identifier for a package, the same DBRM can be bound into different packages. This capability permits program developers to use the same program DBRM for different packages, enabling easy access to tables that have the same structure (DDL) but different owners.

‰

You could use collections to separate programs for different application areas, such as payroll and inventory.

In the JCL, the “Bind a DBRM into a Plan” is as follows: //********************************************************************** //* BIND THE PROGRAM * //********************************************************************** //BIND EXEC PGM=IKJEFT01,COND=(4,LT,LINKEDIT) //STEPLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD //DBRMLIB DD DISP=OLD,DSN=&DBRMLIB(&LOADMEM) //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //********************************************************************** //* SPECIFY YOUR PLAN NAME WITHIN PLAN PARANTHESIS '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PLAN(PLANNAME) MEMBER(PROGRAM) QUALIFIER(USERID) ACTION(REP) RETAIN ISOLATION(UR) VALIDATE(BIND) END /*

Page 121 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 In the JCL, for the “Bind a DBRM into a Plan” you need to provide the following items: ‰

DBRMLIB: DBRM PDS

‰

SYSTSIN: o o o o o

DSN S or DSN SYSTEM: DB2 subsystem PLAN: Name of the plan to be bound MEMBER: DBRM Member name QUALIFIER: USERID ACTION: Add for new plan. If the plan exists, then it will be replaced. Otherwise a new plan is added.

In the JCL, if you want to bind more than one DBRM into a same plan, specify the DBRM member list in MEMBER as follows: Example: //********************************************************************** //* SPECIFY YOUR PLAN NAME WITHIN PLAN PARANTHESIS '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PLAN(PLANNAME) MEMBER(PROGRAM1 PROGRAM2 PROGRAM3) QUALIFIER(USERID) ACTION(REP) RETAIN ISOLATION(UR) VALIDATE(BIND) END /* In the JCL, if you want to bind a DBRM into a package, specify the PACKAGE name and DBRM member in MEMBER as follows. Example: //********************************************************************** //* SPECIFY YOUR PACKAGE NAME WITHIN PACKAGE PARANTHESIS '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PACKAGE (PACKAGE NAME) MEMBER(PROGRAM) QUALIFIER(USERID) -

Page 122 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 ACTION(REP) RETAIN ISOLATION(UR) VALIDATE(BIND) END /* In the JCL, if you want to bind a list of packages into a plan, specify them in PKLIST as follows: Example: //********************************************************************** //* SPECIFY YOUR PACKAGE NAME WITHIN PACKAGE PARANTHESIS '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PLAN (PLAN NAME) PKLIST(PACKAGE1, PACKAGE2) QUALIFIER(USERID) ACTION(REP) RETAIN ISOLATION(UR) VALIDATE(BIND) END /*

Example: A DBRM bind to a plan //SYSTSIN DD * DSN SYSTEM(DSNG) BIND PLAN(Z5938MHD) (Give Plan Name) ACT(REP) ISOLATION(CS) MEMBER(F5938MHD) (Give DBRM Name) OWNER(F5925AP1) VALIDATE(BIND) EXPLAIN(NO) QUALIFIER(F5925DBA) END A list of DBRMs bind to a plan //SYSTSIN DD * DSN SYSTEM(DSNG) BIND PLAN(P5938PB5) (Give Plan Name) ACT(REP) ISOLATION(CS) MEMBER(F5938PB5 F5938LPL) (Give DBRM Name) OWNER(F5925AP1) VALIDATE(BIND) EXPLAIN(NO) -

Page 123 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 QUALIFIER(F5925DBA) END A DBRM bind to a package DSN SYSTEM(DSNG) (Give Sub System) BIND PACKAGE(F5938_T_PROV ) (Give Package Name) OWNER(F5925AP1) QUALIFIER(F5925DBA) MEMBER(F5938PPZ) (Give DBRM Name) VALIDATE(BIND) ISOLATION(CS) RELEASE(COMMIT) ACTION(REP ) END A DBRM bind to a package with the collection and is bound to a plan. In order to specify all the packages in the collection, we can specify as F6418_PB_F6418ACR.* BIND PLAN(F6418PBP) OWNER(F6418DB) QUALIFIER(F6418DB) PKLIST(F6418_PB_F6418ACR.F6418ACR, - (Collection ID: F6418_PB_F6418ACR) F6418_PB_F6418BA1.F6418BA1) ACT(REP) ISOLATION(CS) ACQUIRE(USE) RELEASE(COMMIT) VALIDATE(BIND) ============================================================ BIND PACKAGE (F6418_PB_F6418ACR.F6418ACR) ACT(ADD) ISOLATION(CS) QUALIFIER(F6418DB) OWNER(F6418DB) MEMBER(F641803T) RELEASE(COMMIT) VALIDATE(BIND)

Page 124 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Packages and Plans Storage Actual Plans and Packages are stored in DB2 Directory. Information about the Plans and the Packages are stored in the DB2 catalog.

Compile In the JCL, the compilation for the COBOL is as follows: //********************************************************************** //* COBOL COMPILE * //********************************************************************** //COBCOMP EXEC PGM=IGYCRCTL,COND=(4,LT,DB2PCOMP), // PARM='LIB,XREF,OFFSET,MAP,RENT,RES,NODYNAM,TEST' //SYSIN DD DSN=&&DSNHOUT,DISP=(OLD,DELETE) //SYSLIB DD DSN=&COBCOPY,DISP=SHR //SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSDA, // SPACE=(800,(500,500)) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT3 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT4 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT5

DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA

Page 125 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 //SYSUT6 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT7 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA In the JCL, for compilation you need to provide the following items: ‰

SYSIN: Modified source code

‰

SYSLIB: COBOL Copybook PDS

‰

SYSLIN: Object Module that Is generally specified as a temporary dataset

Link Edit In the JCL, the link edit for the COBOL is as follows: //********************************************************************** //* LINK EDIT THE PROGRAM * //********************************************************************** //LINKEDIT EXEC PGM=IEWL,COND=(4,LT,COBCOMP), // PARM='MAP,LIST,XREF,LET,AMODE=31,RMODE=ANY,RENT,REUS' //SYSLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD // DD DISP=SHR,DSN=CEE.SCEELKED // DD DISP=SHR,DSN=CEE.SCEERUN // DD DISP=SHR,DSN=ISP.SISPLOAD // DD DISP=SHR,DSN=&LOADLIB //SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE) //SYSLMOD DD DISP=SHR,DSN=&LOADLIB(&LOADMEM) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1

DD SPACE=(1024,(50,50)),UNIT=SYSDA

Page 126 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2 In the JCL, for link edit you need to provide the following items: ‰

SYSLIN: Object Module

‰

SYSLMOD: Load module member name with the PDS

Execution At run time, the load module starts up and hits a paragraph containing a CALL to DB2. This CALL contains information such as a description of the consistency token, the content of the SQL host variables, and so on. The CALL invokes the COBOL-DB2 interface program, which connects to DB2 and finds the corresponding plan (or package) with the consistency token and the execution takes place. If there is no correct plan or package with the matching timestamp anywhere in DB2, then you get -805 or -818 error code. The JCL for execution is as follows: //COBDB2RN EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DSN=THYD018.DB2.LOADLIB,DISP=SHR // DD DSN=CEE.SCEERUN,DISP=SHR // DD DSN=DSN810.SDSNLOAD,DISP=SHR //DBRMLIB DD DSN=THYD018.DB2.DBRMLIB,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DSN1) name RUN PROGRAM(FIRSTCD)name PLAN(THYPL018) END

Load Library name

DBRM Name

Subsystem Load module Plan name

/*

Page 127 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved C3: Protected

Handout: DB2

Try It Out Problem Statement: Prepare and execute the program which you have created in Session # 21 (COBOL DB2 application program, to get the hourly rate for a particular rate category supplied by the user). Code: Program Preparation: //THYD018C JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B, // REGION=5M,NOTIFY=&SYSUID //* //********************************************************************** //* INPUT AREA * //********************************************************************** // SET MEMNAME=FIRSTCD