Informix Guide To SQL-Tutorial

Informix Guide to SQL
Tutorial
Version 7.1 December 1994 Part No. 000-7634
Published by INFORMIX Press
Informix Software, Inc. 4100 Bohannon Drive Menlo Park, CA 94025
The following are worldwide trademarks of Informix Software, Inc., or its subsidiaries, registered in the United States of America as indicated by an , and in numerous other countries worldwide: INFORMIX; C-ISAM The following are worldwide trademarks of the indicated owners or their subsidiaries, registered in the United States of America as indicated by an , and in numerous other countries worldwide: X/Open Company Ltd.: UNIX; X/Open Adobe Systems Incorporated: PostScript Some of the products or services mentioned in this document are provided by companies other than Informix. These products or services are identied by the trademark or servicemark of the appropriate companies. If you have a question about one of these products or services, please contact the company in question directly.
Documentation Team:
Sally Cox, Geeta Karmarkar, Susan Koehler, Mary Kraemer, Catherine Lyman, Eileen Wollam
Copyright 1981-1994 by Informix Software, Inc. All Rights Reserved. No part of this work covered by the copyright hereon may be reproduced or used in any form or by any meansgraphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systemswithout permission of the publisher. RESTRICTED RIGHTS LEGEND Software and accompanying materials acquired with United States Federal Government funds or intended for use within or for any United States federal agency are provided with Restricted Rights as dened in DFARS 252.227-7013(c)(1)(ii) or FAR 52.227-19.
ii
Informix Guide to SQL: Tutorial
Preface
This book is a tutorial on the Structured Query Language (SQL) as it is implemented by Informix products. The Informix Guide to SQL: Tutorial and its companion volumes, the Informix Guide to SQL: Reference and the Informix Guide to SQL: Syntax, tell you how to create, manage, and use relational databases with Informix software tools. Examples in this manual represent a number of Informix products and operating systems at different release levels. You must have the following Informix software:
s
An INFORMIX-OnLine Dynamic Server database server or an INFORMIX-SE database server The database server either must be installed on your computer or on another computer to which you are connected over a network.
Either an Informix application development tool, such as INFORMIX-4GL or INFORMIX-NewEra; or an SQL application programming interface (API), such as INFORMIX-ESQL/C; or the DB-Access database access utility, which is shipped as part of your database server The application development tool, SQL API, or DB-Access enables you to compose queries, send them to the database server, and view the results that the database server returns. You can use DB-Access to try out all the SQL statements described in this guide.
Preface
iii
Summary of Chapters
Summary of Chapters
The Informix Guide to SQL: Tutorial includes the following chapters:
s
This Preface provides general information about the book and lists additional reference materials that can help you understand relational database management. The Introduction tells how SQL ts into the Informix family of products and books, explains how to use this book, introduces the demonstration database from which the product examples are drawn, and lists the new features for Version 6.0 of Informix database server products.
Part I Using Basic SQL. This part contains introductory chapters on how to use SQL. Read these chapters rst if you are new to databases and SQL.
s
Chapter 1, Informix Databases, contains an overview of database terminology and denes some important terms and ideas that are used throughout the book. Chapter 2, Composing Simple SELECT Statements, begins the exploration of making simple queries to retrieve and display database data. Chapter 3, Composing Advanced SELECT Statements, discusses making advanced queries to retrieve and display database data. Chapter 4, Modifying Data, describes the statements you use to insert, delete, or update data, and introduces the concepts of database privileges, maintaining data integrity, and archiving data. Chapter 5, Programming with SQL, discusses calling the database server, retrieving rows, and embedding data. Chapter 6, Modifying Data Through SQL Programs, provides an in-depth look at INSERT, DELETE, and UPDATE statements and using these statements in SQL programs. Chapter 7, Programming for a Multiuser Environment, provides a complete discussion on concurrency, isolation levels, and locking.
iv
Summary of Chapters
Part II Designing and Managing Databases. This part contains overview chapters about designing and managing databases. Read these chapters to understand the entity-relationship data model for databases and how to create a database.
s
Chapter 8, Building Your Data Model, describes the components of a data model and provides a step-by-step procedure for building one. Chapter 9, Implementing Your Data Model, tells you how to dene database data types and create a database. Chapter 10, Granting and Limiting Access to Your Database, details how you can ensure data security by granting privileges and using stored procedures and views. Chapter 11, Understanding Informix Networking, discusses networks and how you can best set up a database to work over a network.
Part III Using Advanced SQL. This part contains advanced SQL chapters, such as how to optimize your queries, how to create and use stored procedures, and how to create and use triggers. Read these chapters if you need better performance in your database.
s
Chapter 12, Creating and Using Stored Procedures, describes how to create and use stored procedures. Chapter 13, Creating and Using Triggers, describes how to create and use triggers.
Preface
Informix Welcomes Your Comments
Informix Welcomes Your Comments

A reader-response card is provided with this manual. Please use this card to tell us what you like or dislike about this manual. To help us with future versions of the manual, please tell us about any corrections or clarications that you would nd useful. Return this card to: Informix Software, Inc. Technical Publications Department 4100 Bohannon Drive Menlo Park, CA 94025 If you prefer to share your comments on-line, address your e-mail to: doc@informix.com
Related Reading
If you want additional technical information on database management, consult the following books. The rst book is an introductory text for readers who are new to database management, while the second book is a more complex technical work for SQL programmers and database administrators.
s s
Database: A Primer by C. J. Date (Addison-Wesley Publishing, 1983) An Introduction to Database Systems by C.J. Date (Addison-Wesley Publishing, 1994)
If you are interested in learning more about the SQL language, consider the following books:
s
A Guide to the SQL Standard by C.J. Date with H. Darwen (AddisonWesley Publishing, 1993) Understanding the New SQL: A Complete Guide by J. Melton and A. Simon (Morgan Kaufmann Publishers, 1993) Using SQL by J. Groff and P. Weinberg (Osborne McGraw-Hill, 1990)
vi
Related Reading
This manual assumes that you are familiar with your computer operating system. If you have limited UNIX system experience, you might want to look at your operating system manual or a good introductory text before you read this manual. Some texts about UNIX systems are suggested in the following list:
s
Introducing the UNIX System by H. McGilton and R. Morgan (McGraw-Hill Book Company, 1983) Learning the UNIX Operating System, by G. Todino, J. Strang, and J. Peek (OReilly & Associates, 1993) A Practical Guide to the UNIX System, by M. Sobell (Benjamin/Cummings Publishing, 1989)
UNIX for People by P. Birns, P. Brown, and J. Muster (Prentice-Hall,
1985)
s
UNIX System V: A Practical Guide by M. Sobell (Benjamin/Cummings
Publishing, 1995)
Preface
vii
Table of Contents
Table of Contents
Preface Introduction
Informix Products That Use SQL . Products Covered in This Manual . Other Useful Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 4 5 5 7 8 8 9 10 12 12
How to Use This Manual . . . Typographical Conventions Example Code Conventions Useful On-Line Files . . . .
ASCII and PostScript Error Message Files . The Demonstration Database . . . . . Creating the Demonstration Database . Compliance with Industry Standards . .
New Features in Informix Version 7.1 Products That Use SQL . . . . . . . . . .
Section I Using Basic SQL

Chapter 1 Informix Databases
Databases: What and Why? . . . . . The Data Illustration of a Data Model Concurrent Use and Security . . . Centralized Management . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1-4 1-9 1-10 1-12 1-12 1-16 1-17 1-17 1-18 1-18 1-19 1-19 1-19 1-20 1-20 1-21 1-21 1-22
Important Database Terms . . . . . . . . . . The Relational Model . . . . . . . . . . . Structured Query Language . . Standard SQL . . . . . Informix SQL and ANSI SQL ANSI-Compliant Databases. NLS Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Database Software . . . . . . The Applications . . . . . . The Database Server . . . . . Interactive SQL . . . . . . . Reports and Forms . . . . . . General Programming . . . . Applications and Database Servers Summary . . . . . . . . . .
Chapter 2
Composing Simple SELECT Statements

Introducing the SELECT Statement Some Basic Concepts . . . . The Forms of SELECT. . . . Special Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2-5 2-11 2-11 2-12 2-12 2-18 2-28 2-29
Single-Table SELECT Statements . . . . . . . . Selecting All Columns and Rows . . . . . . . Selecting Specic Columns . . . . . . . . . Using the WHERE Clause . . . . . . . . . Creating a Comparison Condition . . . . . .
x Informix Guide to SQL: Tutorial
Expressions and Derived Values . . . Using Functions in SELECT Statements . Using Stored Procedures in SELECT Statements . . . . . . . .
. . .
. . .
. . .
. . .
2-47 2-53 2-67 2-69 2-69 2-71 2-80 2-84
Multiple-Table SELECT Statements . . . . . . . Creating a Cartesian Product . . . . . . . . Creating a Join . . . . . . . . . . . . . Some Query Shortcuts . . . . . . . . . . . Summary . . . . . . . . . . . . . . . .
Chapter 3
Composing Advanced SELECT Statements

Using the GROUP BY and HAVING Clauses . Using the GROUP BY Clause . . . . . Using the HAVING Clause . . . . . . Creating Advanced Joins . Self-Joins . . . . . Outer Joins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 3-4 3-8 3-11 3-11 3-21 3-31 3-33 3-34 3-35 3-36 3-37 3-41 3-42 3-50 3-52 3-54
Subqueries in SELECT Statements Using ALL . . . . . . . Using ANY . . . . . . Single-Valued Subqueries . Correlated Subqueries . . . Using EXISTS . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set Operations . . . . . . . . . . . . . . . Union . . . . . . . . . . . . . . . . Intersection . . . . . . . . . . . . . . Difference . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . .
Chapter 4
Modifying Data
Statements That Modify Data . . . Deleting Rows . . . . . . . Deleting a Known Number of Rows Inserting Rows . . . . . . . Updating Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4-4 4-5 4-7 4-12
xi
Table of Contents
Database Privileges . . . . . . . . . . . . . 4-16 Displaying Table Privileges . . . . . . . . . 4-18 Data Integrity . . . . . . . . . . . . . . . 4-19 Entity Integrity . . . . . . . . . . . . . 4-19 Semantic Integrity . . . . . . . . . . . . 4-20 Referential Integrity . . . . . . . . . . . . 4-21 Interrupted Modications . . . . . . . . . . . 4-25 The Transaction . . . . . . . . . . . . . 4-26 Transaction Logging . . . . . . . . . . . . 4-26 Specifying Transactions. . . . . . . . . . . 4-27 Archives and Logs . . . . . . . . . . . . . 4-28 Archiving with INFORMIX-SE . . . . . . . . 4-28 Archiving with INFORMIX-OnLine Dynamic Server . . . . . . . . . . 4-29 Concurrency and Locks . . . . . . . . . . . . . . . . . . . . . . . . 4-30 . 4-31 . 4-32 . 4-32
Data Replication . . . . . . . . . INFORMIX-OnLine Dynamic Server Data Replication . . . . . Summary . . . . . . . . . . . .
Chapter 5
Programming with SQL

SQL in Programs . . . . . . . . . SQL in SQL APIs . . . . . . . . SQL in Application Languages . . . Static Embedding . . . . . . . . Dynamic Statements. . . . . . . Program Variables and Host Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 5-4 5-5 5-5 5-5 5-6
Calling the Database Server . . . . . . . . . . 5-8 The SQL Communications Area . . . . . . . . 5-9 The SQLCODE Field . . . . . . . . . . . 5-12 The SQLERRD Array . . . . . . . . . . . 5-13 The SQLWARN Array . . . . . . . . . . . 5-13 The SQLSTATE Value . . . . . . . . . . . 5-14
xii
Retrieving Single Rows . . Data Type Conversion . Dealing with Null Data Dealing with Errors. .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-14 5-16 5-17 5-18 5-21 5-21 5-22 5-23 5-24 5-25 5-28 5-30 5-31 5-33 5-35 5-36 5-36 5-36 5-37 5-40
Retrieving Multiple Rows . . . . . Declaring a Cursor . . . . . . Opening a Cursor . . . . . . Fetching Rows . . . . . . . Cursor Input Modes . . . . . The Active Set of a Cursor . . . Using a Cursor: A Parts Explosion Dynamic SQL . . . . . . . Preparing a Statement . . . Executing Prepared SQL . . Dynamic Host Variables . . Freeing Prepared Statements Quick Execution . . . . . . . . . . . . . . . . .
Embedding Data Denition Statements . . . Embedding Grant and Revoke Privileges . Summary . . . . . . . . . . . . .
Chapter 6
Modifying Data Through SQL Programs

Using DELETE . . . . Direct Deletions . . . Deleting with a Cursor Using INSERT . . . . . Using an Insert Cursor Rows of Constants . . An Insert Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 3 6- 4 6- 7
. 6- 9 . 6- 9 . 6- 12 . 6- 12 . 6- 15 . 6- 15 . 6- 17 . 6- 18
Using UPDATE . . . . . Using an Update Cursor . Cleaning up a Table. . . Summary . . . . . . .
Table of Contents
xiii
Chapter 7
Programming for a Multiuser Environment

Concurrency and Performance Locking and Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 7-3 7-4 7-4
Locking and Performance . Concurrency Issues . . .
How Locks Work . . . . Kinds of Locks . . . . Lock Scope . . . . . The Duration of a Lock . Locks While Modifying.
. 7-6 . 7-6 . 7-7 . 7-9 . 7-10 . 7-11 . 7-11 . 7-12 . 7-13 . 7-13 . 7-15 . 7-16
Setting the Isolation Level . . . . . . Comparing SET TRANSACTION with SET ISOLATION . . . . . ANSI Read Uncommitted and Informix Dirty Read Isolation . . . . ANSI Read Committed and Informix Committed Read Isolation . . Informix Cursor Stability Isolation . . ANSI Serializable, ANSI Repeatable Read and Informix Repeatable Read Isolation . . . . . . Controlling Data Modication with Access Modes . . . . . Setting the Lock Mode . . . Waiting for Locks . . . . Not Waiting for Locks . . Waiting a Limited Time. . Handling a Deadlock . . Handling External Deadlock Simple Concurrency . . . . . .
. . . . . . . . . 7-17 . . . . . . . . . 7-17 . . . . . . . . . 7-17 . . . . . . . . . 7-18 . . . . . . . . . 7-18 . . . . . . . . . 7-19 . . . . . . . . . . . . . . . . . . . . . . . . 7-19 . 7-20 . 7-21 . 7-21
Locking with Other Database Servers . Isolation While Reading . . . . Locking Updated Rows . . . .
xiv
Hold Cursors . Summary . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
7-22 7-23
Section II Designing and Managing Databases

Chapter 8 Building Your Data Model
Why Build a Data Model . . . . . . . . Entity-Relationship Data Model Overview. Identifying and Dening Your Principal Data Objects . . . . . . . . . . Discovering Entities . . . . . . . Dening the Relationships . . . . . Identifying Attributes . . . . . . . Diagramming Your Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 8-4 8-5 8-5 8-9 8-17 8-19 8-23 8-24 8-26 8-30 8-33 8-38
Translating E-R Data Objects Into Relational Constructs . . . . . . . . . . . . . Rules for Dening Tables, Rows, and Columns . . . . . . . . . . . . Determining Keys for Tables . . . . . . . . Resolving Your Relationships . . . . . . . . . . . . . . . . . . . . . . . . .
Normalizing Your Data Model . Summary . . . . . . . .
Chapter 9
Implementing Your Data Model

Dening the Domains Data Types . . . Null Values . . Default Values . Check Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 9-4 9-22 9-22 9-23
Table of Contents
xv
Creating the Database . . . Using CREATE DATABASE Using CREATE TABLE . . Using Command Scripts . Populating the Tables . .
. . . . . . . . . 9-24 . . . . . . . . . 9-24 . . . . . . . . . 9-28 . . . . . . . . . 9-30 . . . . . . . . . 9-31 . . . . . . . . . . . . . . . . . . . . . . . 9-34 . 9-34 . 9-35 . 9-36
Fragmenting Tables and Indexes .
Creating a Fragmented Table . . . . Fragmenting a New Table . . . . Creating A Fragmented Table from Nonfragmented Tables . .
Modifying a Fragmented Table . . . . . . . . . 9-37 Modifying Fragmentation Strategies . . . . . . 9-38 Dropping A Fragment . . . . . . . . . . . 9-40 Accessing Data Stored in Fragmented Tables Use Primary Keys Instead of Rowids . . Summary . . . . . . . . . . . . . . . . . . . . . . . 9-41 . 9-41 . 9-43
Chapter 10
Granting and Limiting Access to Your Database

Controlling Access to Databases . Securing Database Files . . Securing Condential Data . Granting Privileges . . . . Database-Level Privileges . Ownership Rights . . . Table-Level Privileges . . Procedure-Level Privileges Automating Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4 . 11-4 . 11-5 . . . . . . 11-6 11-6 11-8 11-8 11-13 11-13
Controlling Access to Data Using Stored Procedures . . . . . . . Restricting Reads of Data . . . . Restricting Changes to Data . . . Monitoring Changes to Data . . . Restricting Object Creation . . .
. . . . . . 11-16 . . . . . . 11-16 . . . . . . 11-17 . . . . . . 11-18 . . . . . . 11-20
xvi
Using Views . . . . . . . . . . . . . . . 11-21 Creating Views . . . . . . . . . . . . . 11-22 Modifying Through a View . . . . . . . . . 11-25 Privileges and Views . . . . . . Privileges When Creating a View . Privileges When Using a View . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28 . 11-28 . 11-29 . 11-32
Chapter 11
Understanding Informix Networking

What Is a Network? . . . . . . . . . . . . . 12-4
Database Management System Congurations . . . 12-4 A Single-User Conguration . . . . . . . . 12-5 A Local Multiuser Conguration . . . . . . . 12-7 A Remote Conguration . . . . . . . . . . 12-9 Single-Computer Conguration Using Network Communication. . . . . . . 12-10 Distributed Databases . . . . . . . . . . . 12-12 Distributed Databases Using Multiple Vendor Servers . . . . . . . . . . 12-13 Connecting to Data on a UNIX Network . . Example of Client / Server Connections Environment Variables . . . . . . Connection Information . . . . . . SQL Connection Statements . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 12-15 12-16 12-17 12-17
Accessing Tables . . . . . . . . . . . . . . 12-18 Using Synonyms with Table Names . . . . . . 12-19 Synonym Chains . . . . . . . . . . . . 12-20 Protecting Your Data in a Networked Environment . . . . . . . . Data Protection with INFORMIX-SE . . Data Protection with INFORMIX-OnLine Dynamic Server . . . . . . Data Integrity for Distributed Data . . Summary . . . . . . . . . . . . . . . . 12-21 . . . . 12-21 . . . . . . . . . . 12-21 . 12-22 . 12-23
Table of Contents
xvii
Section III Using Advanced SQL

Chapter 12 Creating and Using Stored Procedures
Introduction to Stored Procedures and SPL . . What You Can Do with Stored Procedures . Relationship Between SQL and a Stored Procedure . . . . . . . . . Creating and Using Stored Procedures . . . . Creating a Procedure Using DB-Access . . Creating a Procedure in a Program . . . . Commenting and Documenting a Procedure Diagnosing Compile-Time Errors . . . . Looking at Compile-Time Warnings . . . Generating the Text or Documentation . . Executing a Procedure . . . . . . . . Executing a Stored Procedure Dynamically . Debugging a Procedure . . . . . . . Privileges on Stored Procedures . . Privileges Necessary at Creation Privileges Necessary at Execution Revoking Privileges . . . . . . . . . . . . 14-3 . 14-4 . 14-4
. . . 14-5 . . . 14-6 . . . 14-6 . . . 14-7 . . . 14-7 . . . 14-9 . . . 14-10 . . . 14-11 . . . 14-13 . . . 14-13
. . . . . . . 14-16 . . . . . . . 14-17 . . . . . . . 14-17 . . . . . . . 14-19
Variables and Expressions . . . . . . . . . . . 14-19 Variables . . . . . . . . . . . . . . . . 14-19 SPL Expressions . . . . . . . . . . . . . 14-24 Program Flow Control Branching . . . Looping . . . . Function Handling . . . . . . . . . . . . 14-25 . . . . . . . . . . . . 14-25 . . . . . . . . . . . . 14-26 . . . . . . . . . . . . 14-27
Passing Information into and out of a Procedure . . . 14-28 Returning Results. . . . . . . . . . . . . 14-28
xviii
Exception Handling . . . . . . . . . . . . . 14-31 Trapping an Error and Recovering . . . . . . 14-31 Scope of Control of an ON EXCEPTION Statement . . . . . . . . . . . . 14-32 User-Generated Exceptions . . . . . . . . . 14-34 Summary . . . . . . . . . . . . . . . . 14-36
Chapter 13
Creating and Using Triggers

When to Use Triggers . . . . . . . . . . . . 15-3 15-4 15-5 15-5 15-6 15-7
How to Create a Trigger . . . . . . . . . . . Assigning a Trigger Name . . . . . . . . . Specifying the Trigger Event . . . . . . . . Dening the Triggered Actions . . . . . . . . A Complete CREATE TRIGGER Statement . . .
Using Triggered Actions . . . . . . . . . . . 15-7 Using BEFORE and AFTER Triggered Actions . . . . . . . . . . . . . 15-7 Using FOR EACH ROW Triggered Actions . . . 15-9 Using Stored Procedures as Triggered Actions . . . . . . . . . . . . . 15-11 Tracing Triggered Actions . . . . . . . . . . . 15-13
Generating Error Messages . . . . . . . . . . 15-15 Applying a Fixed Error Message . . . . . . . 15-15 Generating a Variable Error Message. . . . . . 15-17 Summary . . . . . . . . . . . . . . . . 15-18
Index
Table of Contents
xix
xx
Introduction
Introduction
Informix Products That Use SQL . Products Covered in This Manual. Other Useful Documentation . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
3 4 4 5 5 7 8 8 9 10 12 12
How to Use This Manual . . . . Typographical Conventions . Example Code Conventions . Useful On-Line Files . . . . .
ASCII and PostScript Error Message Files . The Demonstration Database . . . . . Creating the Demonstration Database . Compliance with Industry Standards . .
New Features in Informix Version 7.1 Products That Use SQL . . . . . . . . . .
tructured Query Language (SQL) is an English-like language that you can use when creating, managing, and using relational databases. The SQL provided with Informix products is an enhanced version of the industrystandard query language developed by International Business Machines Corporation (IBM). In addition to SQL, Informix provides the Stored Procedure Language (SPL) with which you can write stored procedures. Stored procedures are programs that are stored as database objects.
Informix Products That Use SQL

Informix produces many application development tools and SQL application programming interfaces (API). Application development tools currently available include products such as INFORMIX-SQL, INFORMIX-4GL, and INFORMIX-NewEra. SQL APIs currently available include INFORMIX-ESQL/C and INFORMIX-ESQL/COBOL. The INFORMIX-NewEra development environment can access Informix database servers directly through embedded SQL statements as well as through the call-level interface of the CCL/INFORMIX and CCL/ODBC function libraries. Informix products work with a database server, either INFORMIX-OnLine Dynamic Server, INFORMIX-SE, or an INFORMIX-Gateway product. The DB-Access database-access utility is shipped as a part of each database server. If you are running client applications developed with Version 4.1 and 5.0 application development tools, you use INFORMIX-NET to connect the client to the network.
Introduction
Products Covered in This Manual
Products Covered in This Manual

All the information presented in this manual is valid for the following products. Differences in their use of SQL is indicated where appropriate.
s s s s
INFORMIX-ESQL/C, Version 7.1 INFORMIX-ESQL/COBOL, Version 7.1 INFORMIX-SE, Version 7.1 INFORMIX-OnLine Dynamic Server, Version 7.1
In addition, some examples in this manual are built using Informix products at earlier release levels.
Other Useful Documentation

You can refer to the following related Informix documents that complement this manual:
s
An additional companion volume to the Tutorial, the Informix Guide to SQL: Reference, provides reference information on the types of Informix databases you can create, the data types supported in Informix products, system catalog tables associated with the database, environment variables, and the SQL utilities. This guide also provides a detailed description of the stores7 demonstration database and contains a glossary. An additional companion volume to the Tutorial, the Informix Guide to SQL: Syntax, provides a detailed description of all the SQL statements supported by Informix products. This guide also provides a detailed description of Stored Procedure Language (SPL) statements. The SQL Quick Syntax Guide contains syntax diagrams for all statements and segments described in this manual. You, or whoever installs your Informix products, should refer to the UNIX Products Installation Guide for your particular release to ensure that your Informix product is properly set up before you begin to work with it. A matrix depicting possible client/server congurations is included in the UNIX Products Installation Guide.
How to Use This Manual
Depending on the database server you are using, you or your system administrator need either the INFORMIX-SE Administrators Guide or the INFORMIX-OnLine Dynamic Server Administrators Guide. The DB-Access User Manual describes how to invoke the utility to access, modify, and retrieve information from Informix database servers. When errors occur, you can look them up by number and learn their cause and solution in the Informix Error Messages manual. If you prefer, you can look up the error messages in the on-line message le described in the section ASCII and PostScript Error Message Files on page 8 later in this Introduction and in the Introduction to the Informix Error Messages manual.
How to Use This Manual

This manual assumes that you are using INFORMIX-OnLine Dynamic Server as your database server. Features and behavior specic to INFORMIX-SE are noted throughout the manual. The following sections describe the conventions used in this manual for typographical format, syntax, and example of code.
Typographical Conventions
Informix product manuals use a standard set of conventions to introduce new terms, illustrate screen displays, describe command syntax, and so forth. The following typographical conventions are used throughout this manual: italics New terms, emphasized words, and variables are printed in italics. Database names, table names, column names, le names, utilities, and other similar terms are printed in boldface.
boldface
Introduction
Typographical Conventions
computer
Information that OnLine displays and information that you enter is printed in a computer typeface. All keywords appear in uppercase letters. The diamond symbol appears at the beginning and the end of product-specic information. This symbol indicates a unique identier (primary key) for each table. This symbol indicates a warning. Warnings provide critical information that, if ignored, could cause harm to your database. This symbol indicates important information that you should consider when working with the product.
KEYWORD
3
This symbol indicates a tip. It alerts you to useful information that, for instance, might indicate a shortcut or make it easier to navigate in the product or manual. Additionally, when you are instructed to enter or execute text, immediately press RETURN after the entry. When you are instructed to type the text or press a key, no RETURN is required.
Example Code Conventions
Example Code Conventions

Examples of SQL code occur throughout this manual. Except where noted, the code is not specic to any single Informix application development tool. If only SQL statements are listed in the example, they are not delineated by semicolons. To use this SQL code for a specic product, you must apply the syntax rules for that product. For example, if you are using the Querylanguage option of DB-Access, you must delineate multiple statements with semicolons. If you are using an SQL API, you must use EXEC SQL and a semicolon (or other appropriate delimiters) at the start and end of each statement, respectively. For instance, you might see the following example code:
CONNECT TO stores7 . . . DELETE FROM customer WHERE customer_num = 121 . . . COMMIT WORK DISCONNECT CURRENT
For detailed directions on using SQL statements for a particular application development tool or SQL API, see the manual for your product. Also note that dots in the example indicate that more code would be added in a full application, but it is not necessary to show it to describe the concept being discussed.
Introduction
Useful On-Line Files
Useful On-Line Files

In addition to the Informix set of manuals, the following on-line les, located in the $INFORMIXDIR/release directory, might supplement the information in this manual: Documentation Notes describe features not covered in the manual or that have been modied since publication. The le containing the Documentation Notes for this product is called SQLTDOC_7.1. describe feature differences from earlier versions of Informix products and how these differences might affect current products. The le containing the Release Notes for Version 7.1 of Informix database server products is called SERVERS_7.1. describe any special actions required to congure and use Informix products on your computer. Machine Notes are named for the product described, for example, the Machine Notes le for INFORMIX-OnLine Dynamic Server is ONLINE_7.1.
Release Notes
Machine Notes
Please read these les because they contain vital information about application and performance issues.
ASCII and PostScript Error Message Files

Informix software products provide ASCII les that contain all the Informix error messages and their corrective actions. To access the error messages in the ASCII le, Informix provides scripts that let you display error messages on the screen (nderr) or print formatted error messages (rofferr). See the Introduction to the Informix Error Messages manual for a detailed description of these scripts. The optional Informix Messages and Corrections product provides PostScript les that contain the error messages and their corrective actions. If you have installed this product, you can print the PostScript les on a
The Demonstration Database
PostScript printer. The PostScript error messages are distributed in a number of les of the format errmsg1.ps, errmsg2.ps, and so on. These les are located in the $INFORMIXDIR/msg directory.
The Demonstration Database

The DB-Access utility, which is provided with your Informix database server products, includes a demonstration database called stores7 that contains information about a ctitious wholesale sporting-goods distributor. The sample command les that make up a demonstration application are also included. Most of the examples in this manual are based on the stores7 demonstration database. The stores7 database is described in detail and its contents are listed in Appendix A of the Informix Guide to SQL: Reference. The script that you use to install the demonstration database is called dbaccessdemo7 and is located in the $INFORMIXDIR/bin directory. The database name that you supply is the name given to the demonstration database. If you do not supply a database name, the name defaults to stores7. Follow these rules for naming your database:
s
Names can be up to 18 characters long for INFORMIX-OnLine Dynamic Server databases and up to 10 characters long for INFORMIX-SE databases. The rst character of a name must be a letter or an underscore (_). You can use letters, characters, and underscores (_) for the rest of the name.
DB-Access makes no distinction between uppercase and lowercase
s s
letters.
s
The database name should be unique.
Introduction
Creating the Demonstration Database
When you run dbaccessdemo7, you are, as the creator of the database, the owner and Database Administrator (DBA) of that database. If you installed your Informix database server according to the installation instructions, the les that make up the demonstration database are protected so you cannot make any changes to the original database. You can run the dbaccessdemo7 script again whenever you want to work with a fresh demonstration database. The script prompts you when the creation of the database is complete, and asks if you would like to copy the sample command les to the current directory. Enter N if you have made changes to the sample les and do not want them replaced with the original versions. Enter Y if you want to copy over the sample command les.

Use the following steps to create and populate the demonstration database:
1.
Set the INFORMIXDIR environment variable so that it contains the name of the directory in which your Informix products are installed. Set INFORMIXSERVER to the name of the default database server. The name of the default database server must exist in the $INFORMIXDIR/etc/sqlhosts le. (For a full description of environment variables, see Chapter 4 of the Informix Guide to SQL: Reference.) For more information about sqlhosts, see the INFORMIX-OnLine Dynamic Server Administrators Guide or INFORMIX-SE Administrators Guide. Create a new directory for the SQL command les. Create the directory by entering the following command:
mkdir dirname
2.
3.
Make the new directory the current directory by entering the following command:
cd dirname
10
4.
Create the demonstration database and copy over the sample command les by entering the dbaccessdemo7 command: To create the database without logging enter the following command:
dbaccessdemo7 dbname
To create the demonstration database with logging enter the following command:
dbaccessdemo7 -log dbname
If you are using INFORMIX-OnLine Dynamic Server, by default the data for the database is put into the root dbspace. If you wish, you can specify a dbspace for the demonstration database. To create a demonstration database in a particular dbspace enter the following command:
dbaccessdemo7 dbname -dbspace dbspacename
You can specify all the options in one command as shown in the following command:
dbaccessdemo7 -log dbname -dbspace dbspacename
If you are using INFORMIX-SE, a subdirectory called dbname.dbs is created in your current directory and the database les associated with stores7 are placed there. You will see both data (.dat) and index (.idx) les in the dbname.dbs directory. (If you specify a dbspace name, it will be ignored.) To use the database and the command les that have been copied to your directory, you must have UNIX read and execute permissions for each directory in the pathname of the directory from which you ran the dbaccessdemo7 script. Check with your system administrator for more information about operating-system le and directory permissions. UNIX permissions are discussed in the INFORMIX-OnLine Administrators Guide and the INFORMIX-SE Administrators Guide.
5. 6.
To give someone else the permissions to access the command les in your directory, use the UNIX chmod command. To give someone else the access to the database that you have created, grant them the appropriate privileges using the GRANT statement. To remove privileges, use the REVOKE statement. The GRANT and REVOKE statements are described in Chapter 1 of the Informix Guide to SQL: Syntax.
Introduction 11
Compliance with Industry Standards
Compliance with Industry Standards

The American National Standards Institute (ANSI) has established a set of industry standards for SQL. Informix SQL-based products are fully compliant with SQL-92 Entry Level (published as ANSI X3.L35-1992), which is identical to ISO 9075:1992 on INFORMIX-OnLine Dynamic Server. In addition, many features of OnLine comply with the SQL-92 Intermediate and Full Level and X/Open CAE (common applications environment) standards. Informix SQL-based products are compliant with ANSI SQL-92 Entry Level (published as ANSI X3.135-1992) on INFORMIX-SE with the following exceptions:
s s
Effective checking of constraints Serializable transactions
New Features in Informix Version 7.1 Products That Use SQL

The Introduction to each Version 7.1 product manual contains a list of new features for that product. The Introduction to each manual in the Version 7.1 Informix Guide to SQL series contains a list of new SQL features. A comprehensive listing of all the new features for Version 7.1 Informix products is found in the Release Notes le called SERVERS_7.1. This section highlights the major new features implemented in Version 7.1 of Informix products that use SQL.
s
New FRAGMENT BY clause in the CREATE TABLE statement The CREATE TABLE statement contains a new FRAGMENT BY clause that allows you to create fragmented tables. Fragmentation enables you to dene groups of rows within a table based on a rule and to specify a separate dbspace for each group.
12
New FRAGMENT BY EXPRESSION clause in the CREATE INDEX statement The CREATE INDEX statement contains a new FRAGMENT BY EXPRESSION clause that allows you to create fragmented indexes.
New ALTER FRAGMENT statement You can use the ALTER FRAGMENT statement to dynamically alter an existing table or index-fragmentation strategy as well as to initially create fragments.
New ADD ROWIDS and DROP ROWIDS clauses in the ALTER TABLE statement You can use the ADD ROWIDS clause to add the rowid column to fragmented tables. You can use the DROP ROWIDS clause to drop the rowid column from a fragmented table that has a rowid column.
New FRAGMENTS keyword in INFO statement The FRAGMENTS keyword allows you to display the dbspace names where fragments are located for a specied table.
New SET DATASKIP statement The SET DATASKIP statement allows you to control whether INFORMIX-OnLine Dynamic Server skips any dbspaces in the fragmentation list that are unavailable while a transaction is being processed.
New sysfragments system catalog table The sysfragments table stores fragmentation information for tables and indexes.
New SET PDQPRIORITY statement The SET PDQPRIORITY statement supports the parallel-data-query (PDQ) functionality. PDQ allows queries to be processed in parallel. The SET PDQPRIORITY statement allows an application to set the query priority level dynamically within the application. The query priority level refers to the degree of parallelism to be used for queries.
New output in the SET EXPLAIN statement The output of the SET EXPLAIN statement has been enhanced to support the new fragmentation and PDQ features.
Introduction
13
Changes to the dbexport and dbschema utilities The dbexport and dbschema utilities have been enhanced to support the new fragmentation and PDQ features.
New SET TRANSACTION statement You can now use the ANSI isolation levels for transactions. In addition, the SET TRANSACTION statement permits you to use read-only and read-write access modes.
New TRIM function The TRIM function allows you to strip leading characters or blanks, trailing characters or blanks, or both from a character string.
Support for delimited identiers Delimited identiers allow you to specify as identiers character strings that are otherwise identical to SQL reserved keywords. They also allow you to specify nonalphanumeric characters in database object names and to use lowercase identiers. This feature is only activated when the DELIMIDENT environment variable is set.
WITH REOPTIMIZATION clause for the OPEN CURSOR statement
The WITH REOPTIMIZATION clause allows you to reoptimize a query plan if that query plan becomes deoptimized.
s
INTO clause for the EXECUTE statement
The INTO clause allows you to execute a prepared singleton select statement or execute a prepared EXECUTE PROCEDURE statement. In addition, you can specify output variables using the INTO clause.
s
New environment variables The following environment variables, described in Chapter 4, Environment Variables, of the Informix Guide to SQL: Reference are new in Version 7.1:
u u u u u
DBBLOBBUF DELIMIDENT BUF_FET_SIZE OPTCOMPIND PDQPRIORITY
14
XPG4 SQL CAE compliance

u
X/Open information schemas
The information schema consists of a set of read-only views from which you can retrieve information about any tables, views, and columns to which you have access.
u
Support for CHARACTER VARYING syntax The CHARACTER VARYING data type syntax, which is compliant with XPG4 and ANSI, performs like the Informix data type VARCHAR. The data type supports both a maximum and minimum length.
Specication of cursors as READ ONLY You can specify cursors as READ ONLY with the DECLARE statement.
Optional specication of RESTRICT/CASCADE on the DROP TABLE, DROP VIEW, and REVOKE statements You can now restrict drop and revoke actions with the RESTRICT keyword. Previously, all drop requests to tables and views and revoke requests cascaded to drop all related tables, views, and permissions. Now you can specify the RESTRICT keyword on these statements to disallow the drop or revoke.
Hexadecimal load/unload format This feature allows the LOAD/UNLOAD statements, as well as the dbexport, dbimport, and dbload utilities, to format the nonprintable ASCII characters in hexadecimal format. It affects the formats of unload les if the CHAR/VARCHAR NCHAR/NVARCHAR data types contain nonprintable ASCII characters. It also allows you to load the nonprintable characters from the le into the database after they are prepared in hex format.
Introduction
15
Using Basic SQL
Section I
Chapter
Informix Databases
1
1-3 1-4 1-6 1-7 1-8 1-9 1-10 1-10 1-11 1-12 1-12 1-12 1-13 1-13 1-14 1-14 1-16 1-17 1-17 1-18 1-18 1-19 1-19 1-19 1-20 1-20 1-21 1-21 1-22
Databases: What and Why? . . . . . The Data Illustration of a Data Model Storing Data . . . . . . . Querying Data. . . . . . . Modifying Data . . . . . . Concurrent Use and Security . . . Centralized Management . . . . Group and Private Databases . Essential Databases . . . . . Important Database Terms . . . The Relational Model. . . . Tables . . . . . . . . Columns . . . . . . . Rows . . . . . . . . Tables, Rows, and Columns Operations on Tables . . Structured Query Language . . Standard SQL . . . . . Informix SQL and ANSI SQL ANSI-Compliant Databases NLS Databases . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Database Software . . . . . The Applications . . . . . . The Database Server . . . . . Interactive SQL . . . . . . . Reports and Forms . . . . . General Programming . . . . Applications and Database Servers Summary . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-2
nformix Databases
T
s s s s
his is a book about databases and about how you can exploit them using Informix software. Your real use of a database begins with the SELECT statement, which is described in Chapter 2, Composing Simple SELECT Statements. If you are in a hurry, and if you know at least a little about databases, turn to it now. This chapter covers the fundamental concepts of databases and denes some terms that are used throughout the book, emphasizing the following topics: What makes a database different from a collection of les? What terms are used to describe the main components of a database? What language is used to create, query, and modify a database? What are the main parts of the software that manages a database, and how do these parts work with each other?
Databases: What and Why?

A database is a collection of informationbut so is a simple computer le. What makes a database so special? There must be reasons; otherwise people would not spend so much money, effort, and computer time on databases. Two fundamental differences exist. First, a database comprises not only data but also a plan, or model, of the data. Second, a database can be a common resource, used concurrently by many people.
Informix Databases
1-3
The Data Illustration of a Data Model

The principal difference between information collected in a database and information in a le is in the way the data is organized. A at le is organized physically; certain items precede or follow other items. But the contents of a database are organized according to a data model. A data model is a plan, or map, that denes the units of data and species how each unit is related to the others. For example, a number can appear in either a le or a database. In a le, it is simply a number that occurs at a certain point in the le. A number in a database, however, has a role assigned to it by the data model. It may be a price that is associated with a product that was sold as one item of an order that was placed by a customer. Each of these thingsprices, products, items, orders, and customersare also roles specied by the data model. (See Figure 1-1 on page 1-5.) The data model is designed when the database is created; then units of data are inserted according to the plan laid out in the model. In some books, the term schema is used instead of data model.
1-4
Figure 1-1 Illustration of a data model
1015 06/27/94 1 case baseball gloves $450.00 1014 06/25/94 1 case football 1012 06/18/94 1 case volleyball 1011 06/18/94 5 each tennis racquet 1010 06/17/94 1 case tennis ball $960.00 $ 840.00 $99.00 $36.00 1013 06/22/94 1 each tennis racquet $19.80
ORDERS
order 1001 05/20/94
order 1003 05/22/94 customer Anthony Higgins
item tennis racquet

$19.80
order 1013 06/22/94 item 1 case tennis ball
order 1011 06/18/94
item 2 volleyball nets
Informix Databases
1-5
The Data Illustration of a Data Model Storing Data

Another difference between a database and a le is that the organization of the database is stored with the database. A le may have a complex inner structure, but the denition of that structure is not within the le; it is in the programs that create or use the le. For example, a document le as stored by a word-processing program may contain very detailed structures describing the format of the document. However, only the word-processing program can decipher the contents of the le because the structure is dened within the program, not within the le. A data model, however, is contained in the database it describes. It travels with the database and is available to any program that uses the database. The model denes not only the names of the data items but also their data types, so a program can adapt itself to the database. For example, a program can nd out that, in the current database, a price item is a decimal number with eight digits, two to the right of the decimal point; then it can allocate storage for a number of that type. How programs work with databases is the subject of Chapter 5, Programming with SQL, and Chapter 6, Modifying Data Through SQL Programs.
1-6
The Data Illustration of a Data Model Querying Data

Another difference between a database and a le is the way you can interrogate them. You can search a le sequentially, looking for particular values at particular physical locations in each line or record. That is, you might ask a le, What records have numbers under 20 in the fth eld? Figure 1-2 illustrates this type of search.
Figure 1-2 Searching a le sequentially
1015 06/27/94 1 case baseball gloves$450.00 1013 06/22/94 1 each tennis racquet $19.80 1014 06/25/94 1 case footballs 960.00 06/22/94 1 case tennis ball $36.00 06/22/94 1 case tennis ball $48.00 1012 06/18/94 1 case volleyball $840.00 06/23/94 1011 06/18/94 5 each tennis racquet 1010 06/17/94 1 case tennis ball $99.00 $36.00
ORDERS
In contrast, when you query a database you use the terms dened by its model. To a database, you can pose questions such as, What orders have been placed for products made by the Shimara Corporation, by customers in New Jersey, with ship dates in the third quarter? Figure 1-3 on page 1-8 illustrates this type of query. In other words, when you interrogate data stored in a le, you must state your question in terms of the physical layout of the le. When you query a database, you can ignore the arcane details of computer storage and state your query in terms that reect the real worldat least, to the extent that the data model reects the real world.
Informix Databases
1-7
In this manual, Chapter 2 and Chapter 3 discuss the language you use for making queries. Chapter 8 and Chapter 9 discuss designing an accurate, robust data model for other users to query.
Figure 1-3 Querying a database
order 1019 07/16/94
manufacturer Shimara
order 1016 06/29/94 customer Cathy OBrian order 1023 07/24/94
state New Jersey
customer Bob Shorter
Run: Next Restart Exit Display the next page of query results --------stores7-----------Press CTRL-W for Help------
1019
Bob Shorter
SHM
swim cap
07/16/94
Modifying Data
The model also makes it possible to modify the contents of the database with less chance for error. You can query the database with commands such as Find every stock item with a manufacturer of Presta or Schraeder, and increase its price by 13 percent. You state changes in terms that reect the meaning of the data. You do not have to waste time and effort thinking about details of elds within records in a le, so the chances for error are less. The statements you use to modify stored data are covered in Chapter 5, Programming with SQL.
1-8 Informix Guide to SQL: Tutorial
Concurrent Use and Security
Concurrent Use and Security

A database can be a common resource for many users. Multiple users can query and modify a database simultaneously. The database server (the program that manages the contents of all databases) ensures that the queries and modications are done in sequence and without conict. Having concurrent users on a database provides great advantages but also introduces new problems of security and privacy. Some databases are private; individuals set them up for their own use. Other databases contain condential material that must be shared but among only a select group of persons; still other databases provide public access. Informix database software provides the means to control database use. When you design a database, you can perform any of the following functions:
s s s
Keep the database completely private. Open its entire contents to all users or to selected users. Restrict the selection of data that some users can view. (In fact, you can reveal entirely different selections of data to different groups of users.) Allow specied users to view certain items but not modify them. Allow specied users to add new data but not modify old data. Allow specied users to modify all, or specied items of, existing data. Ensure that added or modied data conforms to the data model.
s s s
The facilities that make these and other things possible are discussed in Chapter 10, Granting and Limiting Access to Your Database.
Informix Databases
1-9
Centralized Management
Databases that are used by many people are highly valuable and must be protected as important business assets. This creates two signicant problems: protecting data and maintaining performance. The INFORMIX-OnLine Dynamic Server database server lets you centralize these tasks. Databases must be guarded against loss or damage. The hazards are many: failures in software and hardware, and the risks of re, ood, and other natural disasters. Losing an important database creates a huge potential for damage. The damage could include not only the expense and difculty of recreating the lost data but also the loss of productive time by the database users as well as the loss of business and good will while users cannot work. A plan for regular archiving of critical databases can help avoid or mitigate these potential disasters. A large database used by many people must be maintained and tuned. Someone must monitor its use of system resources, chart its growth, anticipate bottlenecks, and plan for expansion. Users will report problems in the application programs; someone must diagnose these and correct them. If rapid response is important, someone must study and analyze the performance of the system and nd the causes of slow responses.
Group and Private Databases

Some Informix database servers are designed to manage relatively small databases that are used privately by individuals or that are shared among a small group of users. These database servers (for example, INFORMIX-SE for the UNIX operating system) store databases in les managed by the host operating system. These databases can be archived using the same procedures for backing up les that work with other computer les; that is, copying the les to another medium when they are not in use. The only difference is that when a database is archived its transaction log le must be reset to empty. (The use of transaction logs is discussed in Chapter 7, Programming for a Multiuser Environment. The INFORMIX-OnLine Dynamic Server Administrators Guide and INFORMIX-OnLine Dynamic Server Archive and Backup Guide have more information on archiving.)
1-10
Performance problems that arise in group and private databases are usually related to particular queries that take too long. The INFORMIX-OnLine Dynamic Server Performance Guide deals in depth with the reasons why a query takes more or less time. After you understand all the features of the SELECT statement and the alternative ways of stating a query, as covered in Chapter 2, Composing Simple SELECT Statements, and Chapter 3, Composing Advanced SELECT Statements in this manual, you can use the information in the INFORMIX-OnLine Dynamic Server Performance Guide to understand the performance impact of queries.
Essential Databases
The INFORMIX-OnLine Dynamic Server database server is designed to manage large databases with requirements for high reliability, high availability, and high performance. Although it supports private and group databases very well, it is at its best managing the databases that are essential for your organization to carry out its work.
INFORMIX-OnLine Dynamic Server gives you the ability to make archival
copies while the databases are in use. It also allows incremental archiving (archiving only modied data), an important feature when making a complete copy could take many reels of tape.
INFORMIX-OnLine Dynamic Server has an interactive monitor program by
which its operator (or any user) can monitor the activities within the database server to see when bottlenecks are developing. It also comes with utility programs to analyze its use of disk storage. In addition, OnLine provides the sysmaster tables that contain information about an entire OnLine database server, which might manage many databases. For more information about the sysmaster tables, see the INFORMIX-OnLine Dynamic Server Administrators Guide. The INFORMIX-OnLine Dynamic Server Performance Guide contains tips on optimizing placement of tables on disk. All the details of using and managing OnLine are contained in the INFORMIX-OnLine Dynamic Server Administrators Guide.
Informix Databases
1-11
Important Database Terms
Important Database Terms

You should know two sets of terms before beginning the next chapter. One set of terms describes the database and the data model; the other set describes the computer programs that manage the database.
The Relational Model

Informix databases are relational databases. In technical terms, that means that the data model by which an Informix database is organized is based on the relational calculus devised by E.F. Codd. In practical terms, it means that all data is presented in the form of tables comprising rows and columns.
Tables
A database is a collection of information grouped into one or more tables. A table is an array of data items organized into rows and columns. A demonstration database is distributed with every Informix product. A partial table from the demonstration database is shown in Figure 1-4.
Figure 1-4 The stock table from the demonstration database distributed with all Informix products
stock_num 1 1 1 2 3 4 4 manu_code HRO HSK SMT HRO HSK HSK HRO description baseball gloves baseball gloves baseball gloves baseball baseball bat football football unit_price 250.00 800.00 450.00 126.00 240.00 960.00 480.00 unit case case case case case case case unit_descr 10 gloves/case 10 gloves/case 10 gloves/case 24/case 12/case 24/case 24/case (1 of 2)
1-12
stock_num 5 ... 313
manu_code NRG .... ANZ
description tennis racquet ......... swim cap
unit_price 28.00 ... 60.00
unit each ... box
unit_descr each ...... 12/box (2 of 2)
A table represents all that is known about one entity, one type of thing that the database describes. The example table, stock, represents all that is known about the merchandise that is stocked by a sporting-goods store. Other tables in the demonstration database represent such entities as customer and orders. A database can be thought of as a collection of tables. To create a database is to create a set of tables. The right to query or modify tables can be controlled on a table-by-table basis, so that some users can view or modify some tables and not others.
Columns
Each column of a table stands for one attribute, which is one characteristic, feature, or fact that is true of the subject of the table. The stock table has columns for the following facts about items of merchandise: stock numbers, manufacturer codes, descriptions, prices, and units of measure.
Rows
Each row of a table stands for one instance of the subject of the table, which is, one particular example of that entity. Each row of the stock table stands for one item of merchandise that is sold by the sporting-goods store.
Informix Databases
1-13
The Relational Model Tables, Rows, and Columns

You now understand that the relational model of data is a very simple way of organizing data to reect the world using the following simple coresponding relationships: table = entity column = attribute row = instance A table represents all that the database knows about one subject or kind of thing. A column represents one feature, characteristic, or fact that is true of the table subject. A row represents one individual instance of the table subject.
Some rules apply about how you choose entities and attributes, but they are important only when you are designing a new database. (Database design is covered in Chapter 8 and Chapter 9.) The data model in an existing database already is set. To use the database, you need to know only the names of the tables and columns and how they correspond to the real world.
Operations on Tables
Because a database is really a collection of tables, database operations are operations on tables. The relational model supports three fundamental operations, two of which are illustrated in Figure 1-5 on page 1-15. (All three operations are dened in more detail, with many examples, in Chapter 2, Composing Simple SELECT Statements, and Chapter 3, Composing Advanced SELECT Statements.) To select from a table is to choose certain rows, leaving others aside. One selection that could be made on the stock table is select all rows in which the manufacturer code is HRO and the unit price is between 100.00 and 200.00. To project from a table is to choose certain columns, leaving others aside. One projection that can be made from the stock table is show me the stock_num, unit_descr, and unit_price columns only.
1-14
A table contains information about only one entity; when you want information about multiple entities, you must join their tables. You can join tables in many ways. (The join operation is the subject of Chapter 3, Composing Advanced SELECT Statements.)
Figure 1-5 Illustration of selection of projection
stock Table
stock_num manu_code unitunit_descr 1 HRO case 10 gloves/case 1 HSK case 10 gloves/case 1 SMT case 10 gloves/case 2 HRO case 24/case description baseball gloves baseball gloves baseball gloves baseball unit_price 250.00 800.00
SELECT
450.00 126.00
Informix Databases
1-15
Structured Query Language
Structured Query Language

Most computer software has not yet reached a point where you can literally ask a database, what orders have been placed by customers in New Jersey with ship dates in the second quarter? You must still phrase questions in a restricted syntax that the software can easily parse. You can pose the same question to the demonstration database in the following terms:
SELECT * FROM customer, orders WHERE customer.customer_num = orders.customer_num AND customer.state = 'NJ' AND orders.ship_date BETWEEN DATE('7/1/94') AND DATE('7/30/94')
This question is a sample of Structured Query Language (SQL). It is the language that you use to direct all operations on the database. SQL is composed of statements, each of which begins with one or two keywords that specify a function. The Informix implementation of SQL includes about 76 statements, from ALLOCATE DESCRIPTOR to WHENEVER. All the SQL statements are specied in detail in the Informix Guide to SQL: Syntax. Most of the statements are used infrequentlywhen setting up or tuning a database. People generally use three or four statements to query or update databases. One statement, SELECT, is in almost constant use. It is the only statement that you can use to retrieve data from the database. It is also the most complicated statement, and the next two chapters of this book are devoted to exploring its many uses.
1-16
Standard SQL
Standard SQL
SQL and the relational model were invented and developed at IBM in the early and middle 1970s. Once IBM proved that it was possible to implement practical relational databases and that SQL was a usable language for manipulating them, other vendors began to provide similar products for non-IBM
computers. For reasons of performance or competitive advantage, or to take advantage of local hardware or software features, each SQL implementation differed in small ways from the others and from the IBM version of the language. To ensure that the differences remained small, a standards committee was formed in the early 1980s. Committee X3H2, sponsored by the American National Standards Institute (ANSI), issued the SQL1 standard in 1986. This standard denes a core set of SQL features and the syntax of statements such as SELECT.
Informix SQL and ANSI SQL

The SQL version that is supported by Informix products is highly compatible with standard SQL (it is also compatible with the IBM version of the language). However, it does contain extensions to the standard; that is, extra options or features for certain statements, and looser rules for others. Most of the differences occur in the statements that are not in everyday use. For example, few differences occur in the SELECT statement, which accounts for 90 percent of the SQL use for a typical person. However, the extensions do exist, and that creates a conict. Thousands of Informix customers have embedded Informix-style SQL in programs and stored queries. They rely on Informix to keep its language the same. Other customers require the ability to use databases in a way that conforms exactly to the ANSI standard. They rely on Informix to change its language to conform.
Informix Databases
1-17
ANSI-Compliant Databases
Informix resolved the conict with the following compromise:

s
The Informix version of SQL, with its extensions to the standard, is available by default. You can ask any Informix SQL language processor to check your use of SQL and post a warning ag whenever you use an Informix extension.
This resolution is fair but makes the SQL documentation more complicated. Wherever a difference exists between Informix and ANSI SQL, the Informix Guide to SQL: Syntax describes both versions. Because you probably intend to use only one version, simply ignore the version you do not need.
ANSI-Compliant Databases
You can designate a database as ANSI-compliant by using the MODE ANSI keywords when you create it. Within such a database, certain characteristics of the ANSI standard apply. For example, all actions that modify data automatically take place within a transaction, which means that the changes are made in their entirety or not at all. Differences in the behavior of ANSIcompliant databases are noted where appropriate in the Informix Guide to SQL: Syntax.
NLS Databases
The Version 6.0 and later Informix database servers provide Native Language Support (NLS). This allows you to work in various European or Latin American languages other than English and conform to the customs of a specic locale (various money and date formats, foreign characters in data or identier names, different collation order, and so on). You can activate the NLS functionality by setting the DBNLS environment variable as well as other NLS-specic environment variables. Chapter 4 of the Informix Guide to SQL: Reference describes how to set the NLS environment variables. For additional information on NLS databases, see Chapter 1 in the Informix Guide to SQL: Reference.
1-18
The Database Software
The Database Software

You access your database through two layers of sophisticated software. The top layer, or application, sends commands or queries to the database server. The application calls on the bottom layer, or database server, and gets back information. You command both layers using SQL.
The Applications
A database application, or simply application, is a program that uses the database. It does so by communicating with the database server. At its simplest, the application sends SQL commands to the database server, and the database server sends rows of data back to the application. Then the application displays the rows to you, its user. Alternatively, you command the application to add new data to the database. It incorporates the new data as part of an SQL command to insert a row and passes this command to the database server for execution. Several types of applications exist. Some allow you to access the database interactively using SQL; others present the stored data in different forms related to its use.
The Database Server

The database server is the program that manages the contents of the database as they are stored on disk. The database server knows how tables, rows, and columns are actually organized in physical computer storage. The database server also interprets and executes all SQL commands.
Informix Databases
1-19
Interactive SQL
Interactive SQL
To carry out the examples in this book, and to experiment with SQL and database design for yourself, you need a program that lets you execute SQL statements interactively. DB-Access and INFORMIX-SQL are two such programs. They assist you in composing SQL statements; then they pass your SQL to the database server for execution and display the results to you.
Reports and Forms

After you perfect a query to return precisely the data in which you are interested, you need to format the data for display as a report or form on the terminal screen. ACE is the report generator for INFORMIX-SQL. You provide to ACE a SELECT statement that returns the rows of data and a report specication stating how the pages of the report are to be laid out. ACE compiles this information into a program that you can run whenever you want to produce that report. With INFORMIX-4GL and INFORMIX-NewEra, you can use the 4GL report language to create formatted display.
PERFORM is the module of INFORMIX-SQL that generates interactive screen forms. You prepare a form specication that relates display elds on the screen to columns within tables in the database. PERFORM compiles this specication into a program that you can run at any time. When run, the form program interrogates the database to display a row or rows of data on the screen in the format you specied. You can arrange the form so that the user can type in sample values and have matching rows returned from the database (the query-by-example feature). NewEra provides a Form Painter and a Visual Class Library for display of data in a graphical environment. INFORMIX-4GL also supports form speci-
cation les for screen display of data. For more information on these products, refer to the manuals that come with them.
1-20
General Programming
General Programming
You can write programs that incorporate SQL statements and exchange data with the database server. That is, you can write a program to retrieve data from the database and format it however you choose. You also can write programs that take data from any source in any format, prepare it, and insert it into the database. The most convenient programming languages for this kind of work are NewEra, with an object-oriented language, and INFORMIX-4GL with a procedural language. Both are designed expressly for writing database applications. However, you can also communicate with an Informix database server from programs that contain embedded SQL written in C AND COBOL. You also can write programs called stored procedures to work with database data and objects. The stored procedures that you write are stored directly in a database within tables. You can then execute a stored procedure from DB-Access or an SQL API. Chapter 5, Programming with SQL, and Chapter 6, Modifying Data Through SQL Programs, present an overview of how SQL is used in programs.
Applications and Database Servers

Every program that uses data from a database operates the same way. Regardless of whether it is a packaged program such as ViewPoint Pro, a report program compiled by ACE, or a program that you wrote using INFORMIX-NewEra or an SQL API, you nd the same two layers in every case:
1. 2.
An application that interacts with the user, prepares and formats data, and sets up SQL statements. A database server that manages the database and interprets the SQL.
All the applications make requests of the database server, and only the database server manipulates the database les on disk.
Informix Databases
1-21
Summary
Summary
A database contains a collection of related information but differs in a fundamental way from other methods of storing data. The database contains not only the data but also a data model that denes each data item and species its meaning with respect to the other items and to the real world. A database can be used and even modied by several computer users working concurrently. Different users can be given different views of the contents of a database, and their access to those contents can be restricted in several ways. A database can be crucially important to the success of an organization and can require central administration and monitoring. The OnLine database server caters to the needs of essential applications; both OnLine and INFORMIX-SE support smaller databases for private or group use. You manipulate and query a database using SQL, which was pioneered by IBM and standardized by ANSI. You can take advantage of the Informix extensions to the ANSI-dened language, and your Informix tools also make it possible to maintain strict compliance with ANSI standards. Two layers of software mediate all your work with databases. The bottom layer is always a database server that executes SQL statements and manages the data on disk and in computer memory. The top layer is one of many applications, some from Informix and some written by you or written by other vendors or your colleagues.
1-22
Chapter

Introducing the SELECT Statement Some Basic Concepts . . . . Privileges . . . . . . Relational Operations . . Selection and Projection . Joining . . . . . . . The Forms of SELECT . . . Special Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2-5 2-5 2-5 2-6 2-9 2-11 2-11 2-12 2-12 2-12 2-13 2-14 2-18 2-25 2-27 2-28 2-29 2-38 2-39 2-40 2-43 2-45 2-47 2-47 2-52 2-53 2-53 2-56 2-62 2-67
Single-Table SELECT Statements . . . . . . . Selecting All Columns and Rows. . . . . . Using the Asterisk Symbol (*) . . . . . Reordering the Columns . . . . . . . Sorting the Rows . . . . . . . . . . Selecting Specic Columns . . . . . . . . ORDER BY and Native Language Support . Selecting Substrings . . . . . . . . . Using the WHERE Clause . . . . . . . . Creating a Comparison Condition . . . . . Using Variable Text Searches . . . . . . Using Exact Text Comparisons . . . . . Using a Single-Character Wildcard. . . . MATCHES and Native Language Support . Comparing for Special Characters . . . . Expressions and Derived Values . . . . . . Arithmetic Expressions. . . . . . . . Sorting on Derived Columns . . . . . . Using Functions in SELECT Statements . . . Aggregate Functions . . . . . . . . Time Functions . . . . . . . . . . Other Functions and Keywords . . . . . Using Stored Procedures in SELECT Statements
Multiple-Table SELECT Statements Creating a Cartesian Product . Creating a Join . . . . . . Equi-Join. . . . . . . Natural Join. . . . . . Multiple-Table Join . . . Some Query Shortcuts . . . Using Aliases . . . . . The INTO TEMP Clause . Summary . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-69 2-69 2-71 2-71 2-75 2-78 2-80 2-80 2-83 2-84
2-2
S
s s s
ELECT is the most important and the most complex SQL statement. It is used, along with the SQL statements INSERT, UPDATE, and DELETE, to manipulate data. You can use the SELECT statement in the following ways:
By itself to retrieve data from a database As part of an INSERT statement to produce new rows As part of an UPDATE statement to update information
The SELECT statement is the primary way to query on information in a database. It is your key to retrieving data in a program, report, screen form, or spreadsheet. This chapter shows how you can use the SELECT statement to query on and retrieve data in a variety of ways from a relational database. It discusses how to tailor your statements to select columns or rows of information from one or more tables, how to include expressions and functions in SELECT statements, and how to create various join conditions between relational database tables. This chapter introduces the basic methods for retrieving data from a relational database. More complex uses of SELECT statements, such as subqueries, outer joins, and unions, are discussed in Chapter 3, Composing Advanced SELECT Statements. The syntax and usage for the SELECT statement are described in detail in Chapter 1 of the Informix Guide to SQL: Syntax. Most examples in this chapter come from the tables in the stores7 demonstration database, which is installed with the software for your Informix SQL API or database utility. In the interest of brevity, the examples may show only part of the data that is retrieved for each SELECT statement. See Appendix A in the Informix Guide to SQL: Reference for information on the structure and contents of the stores7 database. For emphasis, keywords are shown in uppercase letters in the examples, although SQL is not case-sensitive.
2-3
Introducing the SELECT Statement
Introducing the SELECT Statement

The SELECT statement is constructed of clauses that let you look at data in a relational database. These clauses let you select columns and rows from one or more database tables or views, specify one or more conditions, order and summarize the data, and put the selected data in a temporary table. This chapter shows how to use ve SELECT statement clauses. You must include these clauses in a SELECT statement in the following order:
1. 2. 3. 4. 5. SELECT clause FROM clause WHERE clause ORDER BY clause INTO TEMP clause
Only the SELECT and FROM clauses are required. These two clauses form the basis for every database query because they specify the tables and columns to be retrieved. Use one or more of the other clauses from the following list:
s s
Add a WHERE clause to select specic rows or create a join condition. Add an ORDER BY clause to change the order in which data is produced. Add an INTO TEMP clause to save the results as a table for further queries.
Two additional SELECT statement clauses, GROUP BY and HAVING, enable you to perform more complex data retrieval. They are introduced in Chapter 3, Composing Advanced SELECT Statements. Another clause, INTO, is used to specify the program or host variable to receive data from a SELECT statement in the INFORMIX-NewEra, INFORMIX-4GL and SQL APIs. Complete syntax and rules for using the SELECT statement are shown in Chapter 1 of the Informix Guide to SQL: Syntax.
2-4
Some Basic Concepts
Some Basic Concepts

The SELECT statement, unlike INSERT, UPDATE, and DELETE statements, does not modify the data in a database. It is used simply to query on the data. Whereas only one user at a time can modify data, multiple users can query on or select the data concurrently. The statements that modify data are discussed in Chapter 4, Modifying Data. The INSERT, UPDATE, and DELETE statements appear in Chapter 1 of the Informix Guide to SQL: Syntax. In a relational database, a column is a data element that contains a particular type of information that occurs in every row in the table. A row is a group of related items of information about a single entity across all columns in a database table. You can select columns and rows from a database table; from a system catalog table, a le that contains information on the database; or from a view, which is a virtual table created to contain a customized set of data. System catalog tables are shown in Chapter 2 of the Informix Guide to SQL: Reference. Views are discussed in Chapter 10, Granting and Limiting Access to Your Database, of this manual.
Privileges
Before you can query on data, you must have the Connect privilege to the database and the Select privilege to the tables in it. These privileges are normally granted to all users. Database access privileges are discussed in Chapter 10, Granting and Limiting Access to Your Database, of this manual and in the GRANT and REVOKE statements in Chapter 1 of the Informix Guide to SQL: Syntax.
Relational Operations
A relational operation involves manipulating one or more tables, or relations, to result in another table. The three kinds of relational operation are selection, projection, and join. This chapter includes examples of selection, projection, and simple joining.
2-5
Some Basic Concepts Selection and Projection

In relational terminology, selection is dened as taking the horizontal subset of rows of a single table that satises a particular condition. This kind of SELECT statement returns some of the rows and all of the columns in a table. Selection is implemented through the WHERE clause of A SELECT statement, as shown in Query 2-1:
Query 2-1
SELECT * FROM customer WHERE state = 'NJ'
Query Result 2-1 contains the same number of columns as the customer table, but only a subset of its rows. Because the data in the selected columns does not t on one line of the DB-Access or INFORMIX-SQL Interactive Schema Editor (ISED) screen, the data is displayed vertically instead of horizontally.
customer_num fname lname company address1 address2 city state zipcode phone customer_num fname lname company address1 address2 city state zipcode phone 119 Bob Shorter The Triathletes Club 2405 Kings Highway Cherry Hill NJ 08002 609-663-6079 122 Cathy OBrian The Sporting Life 543 Nassau Street Princeton NJ 08540 609-342-0054
Query Result 2-1
2-6
Some Basic Concepts
In relational terminology, projection is dened as taking a vertical subset from the columns of a single table that retains the unique rows. This kind of SELECT statement returns some of the columns and all of the rows in a table. Projection is implemented through the select list in the SELECT clause of a SELECT statement, as shown in Query 2-2:
Query 2-2
SELECT UNIQUE city, state, zipcode FROM customer
Query Result 2-2 contains the same number of rows as the customer table, but it projects only a subset of the columns in the table:
city Bartlesville Blue Island Brighton Cherry Hill Denver Jacksonville Los Altos Menlo Park Mountain View Mountain View Oakland Palo Alto Palo Alto Phoenix Phoenix Princeton Redwood City Redwood City Redwood City San Francisco Sunnyvale Sunnyvale Wilmington state zipcode OK NY MA NJ CO FL CA CA CA CA CA CA CA AZ AZ NJ CA CA CA CA CA CA DE 74006 60406 02135 08002 80219 32256 94022 94025 94040 94063 94609 94303 94304 85008 85016 08540 94026 94062 94063 94117 94085 94086 19898
Query Result 2-2
2-7
Some Basic Concepts
The most common kind of SELECT statement uses both selection and projection. A query of this kind, shown in Query 2-3, returns some of the rows and some of the columns in a table:
Query 2-3
SELECT UNIQUE city, state, zipcode FROM customer WHERE state = 'NJ'
Query Result 2-3 contains a subset of the rows and a subset of the columns in the customer table:
Query Result 2-3
city Cherry Hill Princeton state zipcode NJ NJ 08002 08540
2-8
Some Basic Concepts Joining

A join occurs when two or more tables are connected by one or more columns in common, creating a new table of results. The query in the example uses a subset of the items and stock tables to illustrate the concept of a join, as shown in Figure 2-1.
Figure 2-1 Example of a join between two tables
SELECT unique item_num, order_num, stock.stock_num, description FROM items, stock WHERE items.stock_num = stock.stock_num
items Table (example) item_num 1 1 2 3 1 order_num 1001 1002 1002 1003 1005 stock_num 1 4 3 5 5
stock Table (example) stock_num 1 1 2 4 5 manu_code HRO HSK HRO HSK NRG description baseball gloves baseball gloves baseball football tennis racquet
item_num 1 1 3 1
order_num 1001 1002 1003 1005
stock_num 1 4 5 5
description baseball gloves football tennis racquet tennis racquet
2-9
Some Basic Concepts
Query 2-4 joins the customer and state tables:

Query 2-4
SELECT UNIQUE city, state, zipcode, sname FROM customer, state WHERE customer.state = state.code
Query Result 2-4 is composed of specied rows and columns from both the customer and state tables:
Query Result 2-4
city Bartlesville Blue Island Brighton Cherry Hill Denver Jacksonville Los Altos Menlo Park Mountain View Mountain View Oakland Palo Alto Palo Alto Phoenix Phoenix Princeton Redwood City Redwood City Redwood City San Francisco Sunnyvale Sunnyvale Wilmington state zipcode sname OK NY MA NJ CO FL CA CA CA CA CA CA CA AZ AZ NJ CA CA CA CA CA CA DE 74006 60406 02135 08002 80219 32256 94022 94025 94040 94063 94609 94303 94304 85008 85016 08540 94026 94062 94063 94117 94085 94086 19898 Oklahoma New York Massachusetts New Jersey Colorado Florida California California California California California California California Arizona Arizona New Jersey California California California California California California Delaware
2-10
The Forms of SELECT
The Forms of SELECT

Although the syntax remains the same across all Informix products, the form of a SELECT statement and the location and formatting of the resulting output depends on the application. The examples in this chapter and in Chapter 3, Composing Advanced SELECT Statements, display the SELECT statements and their output as they appear when you use the interactive Querylanguage option in DB-Access or INFORMIX-SQL. You also can use SELECT statements to query on data noninteractively through INFORMIX-SQL ACE reports, you can embed them in a language such as INFORMIX-ESQL/C (where they are treated as executable code), you can incorporate them in INFORMIX-4GL as part of its fourth-generation language, or with INFORMIX-NewEra, you can either have them automatically generated or embed them.
Special Data Types

The examples in this chapter use the INFORMIX-OnLine Dynamic Server database server, which enables database applications to include the data types VARCHAR, TEXT, and BYTE. These data types are not available to applications that run on INFORMIX-SE. With the DB-Access or INFORMIX-SQL Interactive Editor, when you issue a SELECT statement that includes one of these three data types, the results of the query are displayed differently.
s
If you execute a query on a VARCHAR column, the entire VARCHAR value is displayed, just as CHARACTER values are displayed. If you select a TEXT column, the contents of the TEXT column are displayed and you can scroll through them. If you query on a BYTE column, the words <BYTE value> are displayed instead of the actual value.
Differences specic to VARCHAR, TEXT, and BYTE are noted as appropriate throughout this chapter. When Native Language Support (NLS) is enabled, you can issue a SELECT statement that queries on NCHAR or NVARCHAR columns instead of their CHAR or VARCHAR counterparts. The NCHAR and NVARCHAR data types allow foreign characters in character data.
Composing Simple SELECT Statements 2-11
Single-Table SELECT Statements
For additional information on these and other data types, see Chapter 9, Implementing Your Data Model, in this manual, and Chapter 3 in the Informix Guide to SQL: Reference.
Single-Table SELECT Statements

You can query a single table in a database in many ways. You can tailor a SELECT statement to perform the following actions:
s s s s
Retrieve all or specic columns Retrieve all or specic rows Perform computations or other functions on the retrieved data Order the data in various ways
Selecting All Columns and Rows

The most basic SELECT statement contains only the two required clauses, SELECT and FROM.
Using the Asterisk Symbol (*)

Query 2-5a species all the columns in the manufact table in a select list. A select list is a list of the column names or expressions that you want to project from a table.
Query 2-5a
SELECT manu_code, manu_name, lead_time FROM manufact
Query 2-5b uses the wildcard asterisk symbol (*), which is shorthand for the select list. The * represents the names of all the columns in the table. You can use the asterisk symbol (*) when you want all the columns, in their dened order.
Query 2-5b
SELECT * FROM manufact
2-12
Query 2-5a and Query 2-5b are equivalent and display the same results; that is, a list of every column and row in the manufact table. Query Result 2-5 shows the results as they would appear on a DB-Access or INFORMIX-SQL ISED screen.
Query Result 2-5
manu_code manu_name SMT ANZ NRG HSK HRO SHM KAR NKL PRC Smith Anza Norge Husky Hero Shimara Karsten Nikolus ProCycle lead_time 3 5 7 5 4 30 21 8 9
Reordering the Columns

Query 2-6 shows how you can change the order in which the columns are listed by changing their order in your select list:
Query 2-6
SELECT manu_name, manu_code, lead_time FROM manufact
Query Result 2-6 includes the same columns as the previous one, but because the columns are specied in a different order, the display is also different:
Query Result 2-6
manu_name Smith Anza Norge Husky Hero Shimara Karsten Nikolus ProCycle manu_code lead_time SMT ANZ NRG HSK HRO SHM KAR NKL PRC 3 5 7 5 4 30 21 8 9
2-13
Selecting All Columns and Rows Sorting the Rows

You can direct the system to sort the data in a specic order by adding an ORDER BY clause to your SELECT statement. The columns you want to use in the ORDER BY clause must be included in the select list either explicitly or implicitly. An explicit select list, shown in Query 2-7a, includes all the column names that you want to retrieve:
Query 2-7a
SELECT manu_code, manu_name, lead_time FROM manufact ORDER BY lead_time
An implicit select list uses the asterisk symbol (*), as shown in Query 2-7b:
Query 2-7b
SELECT * FROM manufact ORDER BY lead_time
Query 2-7a and Query 2-7b produce the same display. Query Result 2-7 shows a list of every column and row in the manufact table, in order of lead_time:
Query Result 2-7
manu_code manu_name SMT HRO HSK ANZ NRG NKL PRC KAR SHM Smith Hero Husky Anza Norge Nikolus ProCycle Karsten Shimara lead_time 3 4 5 5 7 8 9 21 30
2-14
Selecting All Columns and Rows Ascending Order

The retrieved data is sorted and displayed, by default, in ascending order. Ascending order is uppercase A to lowercase z for CHARACTER data types, and lowest to highest value for numeric data types. DATE and DATETIME type data are sorted from earliest to latest, and INTERVAL data is ordered from shortest to longest span of time.
Descending Order
Descending order is the opposite of ascending order, from lowercase z to uppercase A for character types and highest to lowest for numeric data types. DATE and DATETIME data are sorted from latest to earliest, and INTERVAL data is ordered from longest to shortest span of time. Query 2-8 shows an example of descending order:
Query 2-8
SELECT * FROM manufact ORDER BY lead_time DESC
The keyword DESC following a column name causes the retrieved data to be sorted in descending order, as shown in Query Result 2-8:
Query Result 2-8
manu_code manu_name SHM KAR PRC NKL NRG HSK ANZ HRO SMT Shimara Karsten ProCycle Nikolus Norge Husky Anza Hero Smith lead_time 30 21 9 8 7 5 5 4 3
You can specify any column (except TEXT or BYTE) in the ORDER BY clause, and the database server sorts the data based on the values in that column.
2-15
Selecting All Columns and Rows Sorting on Multiple Columns

You can also ORDER BY two or more columns, creating a nested sort. The default is still ascending, and the column listed rst in the ORDER BY clause takes precedence. Query 2-9 and Query 2-10 and corresponding query results show nested sorts. The order in which selected data is displayed is modied by changing the order of the two columns named in the ORDER BY clause.
Query 2-9
SELECT * FROM stock ORDER BY manu_code, unit_price
In Query Result 2-9, the manu_code column data appears in alphabetical order and, within each set of rows with the same manu_code (for example, ANZ, HRO), the unit_price is listed in ascending order:
Query Result 2-9
stock_num manu_code description 5 9 6 313 201 310 301 304 110 205 8 302 309 . . . 113 5 6 1 ANZ ANZ ANZ ANZ ANZ ANZ ANZ ANZ ANZ ANZ ANZ HRO HRO tennis racquet volleyball net tennis ball swim cap golf shoes kick board running shoes watch helmet 3 golf balls volleyball ice pack ear drops unit_price unit unit_descr $19.80 $20.00 $48.00 $60.00 $75.00 $84.00 $95.00 $170.00 $244.00 $312.00 $840.00 $4.50 $40.00 each each case box each case each box case case case each case each each 24 cans/case 12/box each 12/case each 10/box 4/case 24/case 24/case each 20/case
SHM SMT SMT SMT
18-spd, assmbld tennis racquet tennis ball baseball gloves
$685.90 $25.00 $36.00 $450.00
each each case case
each each 24 cans/case 10 gloves/case
2-16
Query 2-10 shows the reversed order of the columns in the ORDER BY clause:
Query 2-10
SELECT * FROM stock ORDER BY unit_price, manu_code
In Query Result 2-10, the data appears in ascending order of unit_price and, where two or more rows have the same unit_price (for example, $20.00, $48.00, $312.00), the manu_code is in alphabetical order:
Query Result 2-10
stock_num manu_code description 302 302 5 9 103 106 5 . . . 301 204 108 6 305 303 311 . . . 110 205 205 205 1 4 102 111 112 7 203 113 1 8 4 HRO KAR ANZ ANZ PRC PRC SMT ice pack ice pack tennis racquet volleyball net frnt derailleur bicycle stem tennis racquet unit_price unit unit_descr $4.50 $5.00 $19.80 $20.00 $20.00 $23.00 $25.00 each each each each each each each each each each each each each each
HRO KAR SHM ANZ HRO PRC SHM
running shoes putter crankset tennis ball first-aid kit socks water gloves
$42.50 $45.00 $45.00 $48.00 $48.00 $48.00 $48.00
each each each case case box box
each each each 24 cans/case 4/case 24 pairs/box 4 pairs/box
HSK ANZ HRO NKL SMT HRO PRC SHM SHM HRO NKL SHM HSK ANZ HSK
helmet 3 golf balls 3 golf balls 3 golf balls baseball gloves football bicycle brakes 10-spd, assmbld 12-spd, assmbld basketball irons/wedge 18-spd, assmbld baseball gloves volleyball football
$308.00 $312.00 $312.00 $312.00 $450.00 $480.00 $480.00 $499.99 $549.00 $600.00 $670.00 $685.90 $800.00 $840.00 $960.00
case case case case case case case each each case case each case case case
4/case 24/case 24/case 24/case 10 gloves/case 24/case 4 sets/case each each 24/case 2 sets/case each 10 gloves/case 24/case 24/case
2-17
Selecting Specic Columns
The order of the columns in the ORDER BY clause is important, and so is the position of the DESC keyword. Although the statements in Query 2-11 contain the same components in the ORDER BY clause, each produces a different result (not shown):
Query 2-11
SELECT * FROM stock ORDER BY manu_code, unit_price DESC SELECT * FROM stock ORDER BY unit_price, manu_code DESC SELECT * FROM stock ORDER BY manu_code DESC, unit_price SELECT * FROM stock ORDER BY unit_price DESC, manu_code

The previous section showed how to select and order all data from a table. However, often all you want to see is the data in one or more specic columns. Again, the formula is to use the SELECT and FROM clauses, specify the columns and table, and perhaps order the data in ascending or descending order with an ORDER BY clause.
2-18
If you want to nd all the customer numbers in the orders table, you would use a statement such as the one in Query 2-12:
Query 2-12
SELECT customer_num FROM orders
Query Result 2-12 shows how the statement simply selects all data in the customer_num column in the orders table and lists the customer numbers on all the orders, including duplicates:
Query Result 2-12
customer_num 101 104 104 104 104 106 106 110 110 111 112 115 116 117 117 119 120 121 122 123 124 126 127
The output includes several duplicates because some customers have placed more than one order. Sometimes you want to see duplicate rows in a projection. At other times, you want to see only the distinct values, not how often each value appears.
2-19
You can cause duplicate rows to be suppressed by including the keyword DISTINCT or its synonym UNIQUE at the start of the select list, as shown in Query 2-13:
Query 2-13
SELECT DISTINCT customer_num FROM orders SELECT UNIQUE customer_num FROM orders
Query 2-13 limits the display to show each customer number in the orders table only once, producing a more readable list, as shown in Query Result 2-13:
Query Result 2-13
customer_num 101 104 106 110 111 112 115 116 117 119 120 121 122 123 124 126 127
2-20
Suppose you are handling a customer call, and you want to locate purchase order number DM354331. You decide to list all the purchase order numbers in the orders table, using a statement such as the one shown in Query 2-14:
Query 2-14
SELECT po_num FROM orders
Query Result 2-14 shows how the statement retrieves data in the po_num column in the orders table:
Query Result 2-14
po_num B77836 9270 B77890 8006 2865 Q13557 278693 LZ230 4745 429Q B77897 278701 B77930 8052 MA003 PC6782 DM354331 S22942 Z55709 W2286 C3288 W9925 KF2961
2-21
However, the list is not in a very useful order. You can add an ORDER BY clause to sort the column data in ascending order and make it easier to nd that particular po_num, as shown in Query Result 2-15:
Query 2-15
SELECT po_num FROM orders ORDER BY po_num
Query Result 2-15

po_num 278693 278701 2865 429Q 4745 8006 8052 9270 B77836 B77890 B77897 B77930 C3288 DM354331 KF2961 LZ230 MA003 PC6782 Q13557 S22942 W2286 W9925 Z55709
2-22
To select multiple columns from a table, list them in the select list in the SELECT clause. Query 2-16 shows the order in which the columns are selected is the order in which they are produced, from left to right:
Query 2-16
SELECT paid_date, ship_date, order_date, customer_num, order_num, po_num FROM orders ORDER BY paid_date, order_date, customer_num
As shown in Sorting on Multiple Columns on page 2-16, you can use the ORDER BY clause to sort the data in ascending or descending order and perform nested sorts. Query Result 2-16 shows descending order:
Query Result 2-16
paid_date ship_date order_date customer_num 106 112 117 117 119 120 101 104 116 106 110 104 104 121 122 111 115 124 127 104 110 126 123 order_num po_num 1004 1006 1007 1012 1016 1017 1002 1003 1005 1014 1008 1001 1013 1018 1019 1009 1010 1021 1023 1011 1015 1022 1020 8006 Q13557 278693 278701 PC6782 DM354331 9270 B77890 2865 8052 LZ230 B77836 B77930 S22942 Z55709 4745 429Q C3288 KF2961 B77897 MA003 W9925 W2286 05/30/1994 05/22/1994 05/30/1994 06/05/1994 05/31/1994 06/29/1994 06/18/1994 07/12/1994 06/29/1994 07/13/1994 07/09/1994 05/26/1994 05/21/1994 05/23/1994 05/22/1994 06/09/1994 05/24/1994 07/03/1994 06/25/1994 07/06/1994 06/07/1994 06/01/1994 05/20/1994 07/10/1994 06/22/1994 07/13/1994 07/10/1994 07/16/1994 07/11/1994 06/21/1994 06/14/1994 06/29/1994 06/17/1994 07/25/1994 07/23/1994 07/30/1994 07/24/1994 07/03/1994 06/18/1994 07/16/1994 06/27/1994 07/30/1994 07/24/1994 07/16/1994 07/11/1994
06/03/1994 06/14/1994 06/21/1994 07/10/1994 07/21/1994 07/22/1994 07/31/1994 08/06/1994 08/06/1994 08/21/1994 08/22/1994 08/22/1994 08/22/1994 08/29/1994 08/31/1994 09/02/1994 09/20/1994
2-23
When you use SELECT and ORDER BY on several columns in a table, you might nd it helpful to use integers to refer to the position of the columns in the ORDER BY clause.The statements in Query 2-17 retrieve and display the same data, shown in Query Result 2-17.
Query 2-17
SELECT customer_num, order_num, po_num, order_date FROM orders ORDER BY 4, 1 SELECT customer_num, order_num, po_num, order_date FROM orders ORDER BY order_date, customer_num
Query Result 2-17

customer_num 104 101 104 106 116 112 117 110 111 115 104 117 104 106 110 119 120 121 122 123 124 126 127 order_num po_num 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 B77836 9270 B77890 8006 2865 Q13557 278693 LZ230 4745 429Q B77897 278701 B77930 8052 MA003 PC6782 DM354331 S22942 Z55709 W2286 C3288 W9925 KF2961 order_date 05/20/1994 05/21/1994 05/22/1994 05/22/1994 05/24/1994 05/30/1994 05/31/1994 06/07/1994 06/14/1994 06/17/1994 06/18/1994 06/18/1994 06/22/1994 06/25/1994 06/27/1994 06/29/1994 07/09/1994 07/10/1994 07/11/1994 07/11/1994 07/23/1994 07/24/1994 07/24/1994
2-24
You can include the DESC keyword in the ORDER BY clause when you assign integers to column names, as shown in Query 2-18:
Query 2-18
SELECT customer_num, order_num, po_num, order_date FROM orders ORDER BY 4 DESC, 1
In this case, data is rst sorted in descending order by order_date and in ascending order by customer_num.
ORDER BY and Native Language Support

You can set the DBNLS environment variable to activate Native Language Support (NLS) functionality. You can then specify a language environment (locale) by setting the LANG environment variable and can set the LC_COLLATE environment variable to further dene the collation order. Query 2-19 uses a SELECT statement with an ORDER BY clause on a column containing data of type NCHAR (the NLS equivalent of CHAR). This NLS table, abonns, is provided separately from the demonstration database; this SELECT statement example is provided as the sel_nls1.sql command le with NLS-enabled DB-Access.
Query 2-19
SELECT numro,nom,prnom FROM abonns ORDER BY nom;
The collation order for the results of this query may vary, depending on the following system variations:
s
Whether NLS is activated and the settings for the LANG and LC_COLLATE environment variables How uppercase versus lowercase letters are handled by the particular system.
2-25
Query Result 2-19a and Query Result 2-19b show two sample sets of output:
Query Result 2-19a
numro 13612 13606 13607 13602 13604 13610 13613 13603 13611 13609 13600 13615 13601 13608 13605 13614 nom Azevedo Dupr Hammer Hmmerle LaFort LeMatre Llanero Montaa Oatfield Tiramis da Sousa di Girolamo lesund taix tker verst prnom Edouardo Freire Michle Franoise Gerhard Greta Jean-Nol Hlose Gloria Dolores Jos Antonio Emily Paolo Alfredo Joo Loureno Antunes Giuseppe Sverre mile Hans-Jrgen Per-Anders
Query Result 2-19a follows the standard ASCII sorting order, which ranks capital letters before lowercase letters and moves the names that start with a capitalized foreign character (lesund, taix, tker, and verst) to the end of the list.
Query Result 2-19b
numro 13601 13612 13600 13615 13606 13608 13607 13602 13604 13610 13613 13603 13611 13605 13614 13609 nom lesund Azevedo da Sousa di Girolamo Dupr taix Hammer Hmmerle LaFort LeMatre Llanero Montaa Oatfield tker verst Tiramis prnom Sverre Edouardo Freire Joo Loureno Antunes Giuseppe Michle Franoise mile Gerhard Greta Jean-Nol Hlose Gloria Dolores Jos Antonio Emily Hans-Jrgen Per-Anders Paolo Alfredo
2-26
Query Result 2-19b indicates that with the appropriate NLS environment variable settings, names starting with foreign characters (lesund, taix, tker, and verst) are collated differently than they are in the standard ASCII order so they are integrated in the list. It does not distinguish between uppercase and lowercase letters.
Selecting Substrings
You can select part of the value of a CHARACTER column by including a substring in the select list. Suppose your marketing department is planning a mailing to your customers and wants a rough idea of their geographical distribution based on zip codes. You could write a query similar to the one shown in Query 2-20:
Query 2-20
SELECT zipcode[1,3], customer_num FROM customer ORDER BY zipcode
2-27
Using the WHERE Clause
Query 2-20 uses a substring to select the rst three characters of the zipcode column (which identify the state) and the full customer_num, and lists them in ascending order by zip code, as shown in Query Result 2-20:
Query Result 2-20
zipcode customer_num 021 080 085 198 322 604 740 802 850 850 940 940 940 940 940 940 940 940 940 940 940 940 940 940 941 943 943 946 125 119 122 121 123 127 124 126 128 120 105 112 113 115 104 116 110 114 106 108 117 111 101 109 102 103 107 118
Using the WHERE Clause

Perhaps you want to see only those orders placed by a particular customer or the calls entered by a particular customer service representative. You can add a WHERE clause to a SELECT statement to retrieve these specic rows from a table. You can use the WHERE clause to set up a comparison condition or a join condition. This section demonstrates only the rst use. Join conditions are described in a later section and in the next chapter.
2-28
Creating a Comparison Condition
The set of rows returned by a SELECT statement is the active set for that statement. A singleton SELECT statement returns a single row. In INFORMIX-4GL or an SQL API, the retrieval of multiple rows requires the use of a cursor. In NewEra, you use a SuperTable to handle multiple row retrieval. See Chapter 5, Programming with SQL, and Chapter 6, Modifying Data Through SQL Programs.

The WHERE clause of a SELECT statement species the rows you want to see. A comparison condition employs specic keywords and operators to dene the search criteria. For example, you might use one of the keywords BETWEEN, IN, LIKE, or MATCHES to test for equality, or the keywords IS NULL to test for null values. You can combine the keyword NOT with any of these keywords to specify the opposite condition. Figure 2-2 lists the relational operators you can use in a WHERE clause in place of a keyword to test for equality:
Figure 2-2 Relational operators that test for equality
Operator = != or <> > >= < <= Operation equals does not equal greater than greater than or equal to less than less than or equal to
2-29
For CHAR expressions, greater than means after in ASCII collating order, where lowercase letters are after uppercase letters, and both are after numerals. See the ASCII Character Set chart in Chapter 1 of the Informix Guide to SQL: Syntax. For DATE and DATETIME expressions, greater than means later in time, and for INTERVAL expressions, it means of longer duration. You cannot use TEXT or BYTE columns in string expressions, except when you test for null values. You can use the preceding keywords and operators in a WHERE clause to create comparison condition queries that perform the following actions:
s s s s s
Include values Exclude values Find a range of values Find a subset of values Identify null values
You can also use the preceding keywords and operators in a WHERE clause to create comparison condition queries, which perform variable text searches using the following criteria:
s s s s s
Exact text comparison Single-character wildcards Restricted single-character wildcards Variable-length wildcards Subscripting
The following section contains examples that illustrate these types of queries.
2-30
Creating a Comparison Condition Including Rows

Use the relational operator = to include rows in a WHERE clause, as shown in Query 2-21:
Query 2-21
SELECT customer_num, call_code, call_dtime, res_dtime FROM cust_calls WHERE user_id = 'maryj'
Query 2-21 returns the set of rows shown in Query Result 2-21:
Query Result 2-21
customer_num call_code call_dtime 106 D 121 O 127 I res_dtime
1994-06-12 08:20 1994-06-12 08:25 1994-07-10 14:05 1994-07-10 14:06 1994-07-31 14:30
Excluding Rows
Use the relational operators != or <> to exclude rows in a WHERE clause. Query 2-22 assumes that you are selecting from an ANSI-compliant database; the statements specify the owner or login name of the creator of the customer table. This qualier is not required when the creator of the table is the current user, or when the database is not ANSI-compliant. However, it is not incorrect to include the qualier in either case. For a complete discussion of owner naming, see Chapter 1 in the Informix Guide to SQL: Syntax.
Query 2-22
SELECT customer_num, company, city, state FROM odin.customer WHERE state != 'CA' SELECT customer_num, company, city, state FROM odin.customer WHERE state <> 'CA'
2-31
Both statements in Query 2-22 exclude values by specifying that, in the customer table owned by the user odin, the value in the state column should not be equal to CA, as shown in Query Result 2-22
Query Result 2-22
customer_num 119 120 121 122 123 124 125 126 127 128 company The Triathletes Club Century Pro Shop City Sports The Sporting Life Bay Sports Putnums Putters Total Fitness Sports Neelies Discount Sp Big Blue Bike Shop Phoenix College city Cherry Hill Phoenix Wilmington Princeton Jacksonville Bartlesville Brighton Denver Blue Island Phoenix state NJ AZ DE NJ FL OK MA CO NY AZ
Specifying Rows
Query 2-23 shows two ways to specify rows in a WHERE clause:
Query 2-23
SELECT catalog_num, stock_num, manu_code, cat_advert FROM catalog WHERE catalog_num BETWEEN 10005 AND 10008 SELECT catalog_num, stock_num, manu_code, cat_advert FROM catalog WHERE catalog_num >= 10005 AND catalog_num <= 10008
2-32
Each statement in Query 2-23 species a range for catalog_num from 10005 through 10008, inclusive. The rst statement uses keywords, and the second uses relational operators to retrieve the rows shown in Query Result 2-23:
Query Result 2-23
catalog_num stock_num manu_code cat_advert catalog_num stock_num manu_code cat_advert te catalog_num stock_num manu_code cat_advert catalog_num stock_num manu_code cat_advert 10005 3 HSK High-Technology Design Expands the Sweet Spot 10006 3 SHM Durable Aluminum for High School and Collegia Athletes 10007 4 HSK Quality Pigskin with Joe Namath Signature 10008 4 HRO Highest Quality Football for High School and Collegiate Competitions
Note that although the catalog table includes a column with the BYTE data type, that column is not included in this SELECT statement because the output would show only the words <BYTE value> by the column name. You can display TEXT and BYTE values by using the PROGRAM attribute when using forms in INFORMIX-SQL or INFORMIX-4GL or by writing a NewEra, 4GL or an SQL API application to do so.
2-33
Creating a Comparison Condition Excluding a Range of Rows

In Query 2-24, by using the keywords NOT BETWEEN, the condition excludes rows that have the character range 94000 through 94999 in the zipcode column, as shown in Query Result 2-24:
Query 2-24
SELECT fname, lname, company, city, state FROM customer WHERE zipcode NOT BETWEEN '94000' AND '94999' ORDER BY state
Query Result 2-24

fname Fred Frank Eileen Jason Marvin James Bob Cathy Kim Chris lname Jewell Lessor Neelie Wallack Hanlon Henry Shorter OBrian Satifer Putnum company Century* Pro Shop Phoenix University Neelies Discount Sp City Sports Bay Sports Total Fitness Sports The Triathletes Club The Sporting Life Big Blue Bike Shop Putnums Putters city Phoenix Phoenix Denver Wilmington Jacksonville Brighton Cherry Hill Princeton Blue Island Bartlesville state AZ AZ CO DE FL MA NJ NJ NY OK
Using a WHERE Clause to Find a Subset of Values

As shown in Excluding Rows on page 2-31, Query 2-25 also assumes the use of an ANSI-compliant database. The owner qualier is in quotation marks to preserve the case-sensitivity of the literal string.
Query 2-25
SELECT lname, city, state, phone FROM 'Aleta'.customer WHERE state = 'AZ' OR state = 'NJ' ORDER BY lname SELECT lname, city, state, phone FROM 'Aleta'.customer WHERE state IN ('AZ', 'NJ') ORDER BY lname
2-34
Each statement in Query 2-25 retrieves rows that include the subset of AZ or NJ in the state column of the Aleta.customer table, as shown in Query Result 2-25:
Query Result 2-25
lname Jewell Lessor OBrian Shorter city Phoenix Phoenix Princeton Cherry Hill state phone AZ AZ NJ NJ 602-265-8754 602-533-1817 609-342-0054 609-663-6079
Note that you cannot test a TEXT or BYTE column with the IN keyword. In Query 2-26, an example of a query on an ANSI-compliant database, no quotation marks exist around the table owner name. Whereas the two statements in Query 2-25 searched the Aleta.customer table, Query 2-26 searches the table ALETA.customer, which is a different table, because of the way ANSI-compliant databases look at owner names.
Query 2-26
SELECT lname, city, state, phone FROM Aleta.customer WHERE state NOT IN ('AZ', 'NJ') ORDER BY state
2-35
In Query 2-26, by adding the keyword NOT IN, the subset changes to exclude the subsets AZ and NJ in the state column. Query Result 2-26 shows the results in order of the state column:
Query Result 2-26
lname Pauli Sadler Currie Higgins Vector Watson Ream Quinn Miller Jaeger Keyes Lawson Beatty Albertson Grant Parmelee Sipes Baxter Neelie Wallack Hanlon Henry Satifer Putnum city Sunnyvale San Francisco Palo Alto Redwood City Los Altos Mountain View Palo Alto Redwood City Sunnyvale Redwood City Sunnyvale Los Altos Menlo Park Redwood City Menlo Park Mountain View Redwood City Oakland Denver Wilmington Jacksonville Brighton Blue Island Bartlesville state phone CA CA CA CA CA CA CA CA CA CA CA CA CA CA CA CA CA CA CO DE FL MA NY OK 408-789-8075 415-822-1289 415-328-4543 415-368-1100 415-776-3249 415-389-8789 415-356-9876 415-544-8729 408-723-8789 415-743-3611 408-277-7245 415-887-7235 415-356-9982 415-886-6677 415-356-1123 415-534-8822 415-245-4578 415-655-0011 303-936-7731 302-366-7511 904-823-4239 617-232-4159 312-944-5691 918-355-2074
2-36
Creating a Comparison Condition Identifying Null Values

Use the IS NULL or IS NOT NULL option to check for null values. A null represents either the absence of data or a value that is unknown or not applicable. A null value is not the same as a zero or a blank. Query 2-27 returns all rows that have a null paid_date, as shown in Query Result 2-27:
Query 2-27
SELECT order_num, customer_num, po_num, ship_date FROM orders WHERE paid_date IS NULL ORDER BY customer_num
Query Result 2-27

order_num 1004 1006 1007 1012 1016 1017 customer_num 106 112 117 117 119 120 po_num 8006 Q13557 278693 278701 PC6782 DM354331 ship_date 05/30/1994 06/05/1994 06/29/1994 07/12/1994 07/13/1994
Forming Compound Conditions

You can connect two or more comparison conditions, or Boolean expressions, by using the logical operators AND, OR, and NOT. A Boolean expression evaluates as true or false or, if null values are involved, as unknown. You can use TEXT or BYTE objects in a Boolean expression only when you test for a null value. In Query 2-28, the operator AND combines two comparison expressions in the WHERE clause:
Query 2-28
SELECT order_num, customer_num, po_num, ship_date FROM orders WHERE paid_date IS NULL AND ship_date IS NOT NULL ORDER BY customer_num
2-37
The query returns all rows that have a null paid_date and the ones that do not also have a null ship_date, as shown in Query Result 2-28:
Query Result 2-28
order_num customer_num po_num 1004 1007 1012 1016 1017 106 117 117 119 120 8006 278693 278701 PC6782 DM354331 ship_date 05/30/1994 06/05/1994 06/29/1994 07/12/1994 07/13/1994
Using Variable Text Searches

You can use the keywords LIKE and MATCHES for variable text queries based on substring searches of CHARACTER elds. Include the keyword NOT to indicate the opposite condition. The keyword LIKE is the ANSI standard, whereas MATCHES is an Informix extension. Variable text search strings can include the wildcards listed in Figure 2-3 with LIKE or MATCHES.
Figure 2-3 Wildcards used with LIKE and MATCHES
Symbol LIKE % _ \ MATCHES * ? [] \ evaluates to zero or more characters evaluates to a single character (except null) evaluates to single character or range of values escapes special signicance of next character evaluates to zero or more characters evaluates to a single character escapes special signicance of next character Meaning
You cannot test a TEXT or BYTE column with LIKE or MATCHES.

Creating a Comparison Condition Using Exact Text Comparisons

The following examples include a WHERE clause that searches for exact text comparisons by using the keyword LIKE or MATCHES or the equal sign (=) relational operator . Unlike earlier examples, these examples illustrate how to query on an external table in an ANSI-compliant database. An external table is a table that is not in the current database. You can access only external tables that are part of an ANSI-compliant database. Whereas the database used previously in this chapter was the demonstration database called stores7, the FROM clause in the following examples species the manatee table, created by the owner bubba, which resides in an ANSIcompliant database named syzygy. For more information on dening external tables, see Chapter 1 in the Informix Guide to SQL: Syntax. Each statement in Query 2-29 retrieves all the rows that have the single word helmet in the description column as shown in Query Result 2-29:
Query 2-29
SELECT * FROM syzygy:bubba.manatee WHERE description = 'helmet' ORDER BY mfg_code SELECT * FROM syzygy:bubba.manatee WHERE description LIKE 'helmet' ORDER BY mfg_code SELECT * FROM syzygy:bubba.manatee WHERE description MATCHES 'helmet' ORDER BY mfg_code
Query Result 2-29

stock_no mfg_code 991 991 991 991 991 ANT BKE JSK PRM SHR description helmet helmet helmet helmet helmet unit_price unit unit_type $222.00 $269.00 $311.00 $234.00 $245.00 case case each case case 4/case 4/case 4/case 4/case 4/case
2-39
Creating a Comparison Condition Using a Single-Character Wildcard

The statements in Query 2-30 illustrate the use of a single-character wildcard in a WHERE clause. Further, they demonstrate a query on an external table. The stock table is in the external database sloth, which, beside being outside the current stores7 database, is on a separate database server called meerkat. For details on external tables, external databases, and networks, see Chapter 11, Understanding Informix Networking, in this manual and Chapter 1 in the Informix Guide to SQL: Syntax.
Query 2-30
SELECT * FROM sloth@meerkat:stock WHERE manu_code LIKE '_R_' AND unit_price >= 100 ORDER BY description, unit_price SELECT * FROM sloth@meerkat:stock WHERE manu_code MATCHES '?R?' AND unit_price >= 100 ORDER BY description, unit_price
Each statement in Query 2-30 retrieves only those rows for which the middle letter of the manu_code is R, as shown in Query Result 2-30:
Query Result 2-30
stock_num manu_code description 205 2 1 7 102 114 4 110 110 307 306 308 304 HRO HRO HRO HRO PRC PRC HRO PRC HRO PRC PRC PRC HRO 3 golf balls baseball baseball gloves basketball bicycle brakes bicycle gloves football helmet helmet infant jogger tandem adapter twin jogger watch unit_price unit unit_descr $312.00 $126.00 $250.00 $600.00 $480.00 $120.00 $480.00 $236.00 $260.00 $250.00 $160.00 $280.00 $280.00 case case case case case case case case case each each each box 24/case 24/case 10 gloves/case 24/case 4 sets/case 10 pairs/case 24/case 4/case 4/case each each each 10/box
2-40
The comparison '_R_' (for LIKE) or '?R?' (for MATCHES) species, from left to right, the following items:
s s s
Any single character The letter R Any single character
WHERE Clause with Restricted Single-Character Wildcard

Query 2-31 selects only those rows where the manu_code begins with A through H and returns the rows shown in Query Result 2-31. The class test '[A-H]' species any single letter from A through H, inclusive. No equivalent wildcard symbol exists for the LIKE keyword.
Query 2-31
SELECT * FROM stock WHERE manu_code MATCHES '[A-H]*' ORDER BY description, manu_code, unit_price
Query Result 2-31

stock_num manu_code description 205 205 2 3 1 1 7 . . . 110 110 110 . . . 301 301 313 6 5 8 9 304 304 ANZ HRO HRO HSK HRO HSK HRO 3 golf balls 3 golf balls baseball baseball bat baseball gloves baseball gloves basketball unit_price unit unit_descr $312.00 $312.00 $126.00 $240.00 $250.00 $800.00 $600.00 case case case case case case case 24/case 24/case 24/case 12/case 10 gloves/case 10 gloves/case 24/case
ANZ HRO HSK
helmet helmet helmet
$244.00 case 4/case $260.00 case 4/case $308.00 case 4/case
ANZ HRO ANZ ANZ ANZ ANZ ANZ ANZ HRO
running shoes running shoes swim cap tennis ball tennis racquet volleyball volleyball net watch watch
$95.00 $42.50 $60.00 $48.00 $19.80 $840.00 $20.00 $170.00 $280.00
each each box case each case each box box
each each 12/box 24 cans/case each 24/case each 10/box 10/box
2-41
Creating a Comparison Condition WHERE Clause with Variable-Length Wildcard

The statements in Query 2-32 use a wildcard at the end of a string to retrieve all the rows where the description begins with the characters bicycle:
Query 2-32
SELECT * FROM stock WHERE description LIKE 'bicycle%' ORDER BY description, manu_code SELECT * FROM stock WHERE description MATCHES 'bicycle*' ORDER BY description, manu_code
Either statement returns the rows found in Query Result 2-32:

Query Result 2-32
stock_num manu_code description 102 102 114 107 106 101 101 105 105 PRC SHM PRC PRC PRC PRC SHM PRC SHM bicycle bicycle bicycle bicycle bicycle bicycle bicycle bicycle bicycle brakes brakes gloves saddle stem tires tires wheels wheels unit_price unit unit_descr $480.00 $220.00 $120.00 $70.00 $23.00 $88.00 $68.00 $53.00 $80.00 case case case pair each box box pair pair 4 sets/case 4 sets/case 10 pairs/case pair each 4/box 4/box pair pair
The comparison 'bicycle%' or 'bicycle*' species the characters bicycle followed by any sequence of zero or more characters. It matches bicycle stem with stem matched by the wildcard. It matches to the characters bicycle alone, if a row exists with that description. Query 2-33 narrows the search by adding another comparison condition that excludes a manu_code of PRC:
Query 2-33
SELECT * FROM stock WHERE description LIKE 'bicycle%' AND manu_code NOT LIKE 'PRC' ORDER BY description, manu_code
2-42
The statement retrieves only the rows found in Query Result 2-33:
Query Result 2-33
stock_num manu_code description 102 SHM 101 SHM 105 SHM bicycle brakes bicycle tires bicycle wheels unit_price unit unit_descr $220.00 case 4 sets/case $68.00 box 4/box $80.00 pair pair
When you select from a large table and use an initial wildcard in the comparison string (such as '%cycle'), the query often takes longer to execute. This is because indexes cannot be used, so every row is searched.
MATCHES and Native Language Support

As indicated on page 2-25, you can set the DBNLS, LANG, and LC_COLLATE environment variables to inuence NLS functionality regarding the collation order of data returned by a query. Query 2-34 uses an ORDER BY clause and a WHERE clause specifying a matching range on a column containing data of type NCHAR. This NLS table, abonns, is provided separately from the demonstration database. Query 2-34 is provided as the sel_nls2.sql command le with NLS-enabled DB-Access.
Query 2-34
SELECT numro,nom,prnom FROM abonns WHERE nom MATCHES '[E-P]*' ORDER BY nom;
2-43
The output in Query Result 2-34a and Query Result 2-34b show different rows selected for the MATCHES range by the same query, based on different NLS environment variable settings:
Query Result 2-34a
numro 13607 13602 13604 13610 13613 13603 13611 nom Hammer Hmmerle LaFort LeMatre Llanero Montaa Oatfield prnom Gerhard Greta Jean-Nol Hlose Gloria Dolores Jos Antonio Emily
In Query Result 2-34a, the rows for taix, tker, and verst are not selected and listed because, with standard ASCII ordering, the accented rst letter of each name is not in the E-P MATCHES range for the nom column.
Query Result 2-34b
numro 13608 13607 13602 13604 13610 13613 13603 13611 13605 13614 nom taix Hammer Hmmerle LaFort LeMatre Llanero Montaa Oatfield tker verst prnom mile Gerhard Greta Jean-Nol Hlose Gloria Dolores Jos Antonio Emily Hans-Jrgen Per-Anders
In Query Result 2-34b, the rows for taix, tker, and verst are included in the list because, with the appropriate NLS environment variable settings, the accented rst letter of each name is in the E-P MATCHES range for the nom column.
2-44
Creating a Comparison Condition Comparing for Special Characters

Query 2-35 uses the keyword ESCAPE with LIKE or MATCHES so you can protect a special character from misinterpretation as a wildcard symbol:
Query 2-35
SELECT * FROM cust_calls WHERE res_descr LIKE '%!%%' ESCAPE '!'
The ESCAPE keyword designates an escape character (it is an exclamation point (!) in this example), which protects the next character so it is interpreted as data and not as a wildcard. In the example, the escape character causes the middle percent sign (%) to be treated as data. By using the ESCAPE keyword, you can search for occurrences of a percent sign (%) in the res_descr column using the LIKE wildcard percent sign (%). The query retrieves the row shown in Query Result 2-35:
Query Result 2-35
customer_num call_dtime user_id call_code call_descr 116 1993-12-21 11:24 mannyn I Second complaint from this customer! Received two cases right-handed outfielder gloves (1 HRO) instead of one case lefties. 1993-12-27 08:19 Memo to shipping (Ava Brown) to send case of left-handed gloves, pick up wrong case; memo to billing requesting 5% discount to placate customer due to second offense and lateness of resolution because of holiday
res_dtime res_descr
Using Subscripting in a WHERE Clause

You can use subscripting in the WHERE clause of a SELECT statement to specify a range of characters or numbers in a column, as shown in Query 2-36:
Query 2-36
SELECT catalog_num, stock_num, manu_code, cat_advert, cat_descr FROM catalog WHERE cat_advert[1,4] = 'High'
The subscript [1,4] causes Query 2-36 to retrieve all rows in which the rst four letters of the cat_advert column are High, as shown in Query Result 2-36:
2-45
Query Result 2-36

catalog_num stock_num manu_code cat_advert 10004 2 HRO Highest Quality Ball Available, from Hand-Stitching to the Robinson Signature
cat_descr Jackie Robinson signature ball. Highest professional quality, used by National League. catalog_num 10005 stock_num 3 manu_code HSK cat_advert High-Technology Design Expands the Sweet Spot cat_descr Pro-style wood. Available in sizes: 31, 32, 33, 34, 35. catalog_num stock_num manu_code cat_advert 10008 4 HRO Highest Quality Football for High School and Collegiate Competitions
cat_descr NFL-style, pigskin.
catalog_num 10012 stock_num 6 manu_code SMT cat_advert High-Visibility Tennis, Day or Night cat_descr Soft yellow color for easy visibility in sunlight or artificial light. catalog_num stock_num manu_code cat_advert 10043 202 KAR High-Quality Woods Appropriate for High School Competitions or Serious Amateurs
cat_descr Full set of woods designed for precision control and power performance. catalog_num stock_num manu_code cat_advert 10045 204 KAR High-Quality Beginning Set of Irons Appropriate for High School Competitions
cat_descr Ideally balanced for optimum control. Nylon covered shaft. catalog_num 10068 stock_num 310 manu_code ANZ cat_advert High-Quality Kickboard cat_descr White. Standard size.
2-46
Expressions and Derived Values

You are not limited to selecting columns by name. You can use the SELECT clause of a SELECT statement to perform computations on column data and to display information derived from the contents of one or more columns. You do this by listing an expression in the select list. An expression consists of a column name, a constant, a quoted string, a keyword, or any combination of these items connected by operators. It also can include host variables (program data) when the SELECT statement is embedded in a program. For more information, see the section Expression, in Chapter 1 of the Informix Guide to SQL: Syntax.
Arithmetic Expressions
An arithmetic expression contains at least one of the arithmetic operators listed in Figure 2-4 and produces a number. You cannot use TEXT or BYTE columns in arithmetic expressions.
Figure 2-4 Arithmetic operators used in arithmetic expressions
Operator + * / Operation addition subtraction multiplication division
Operations of this nature enable you to see the results of proposed computations without actually altering the data in the database. You can add an INTO TEMP clause to save the altered data in a temporary table for further
2-47
reference, computations, or impromptu reports. Query 2-37 calculates a 7 percent sales tax on the unit_price column when the unit_price is $400 or more (but does not update it in the database).
Query 2-37
SELECT stock_num, description, unit, unit_descr, unit_price, unit_price * 1.07 FROM stock WHERE unit_price >= 400
If you are using the DB-Access or INFORMIX-SQL ISED, the result is displayed in a column labeled expression, as shown in Query Result 2-37:
Query Result 2-37
stock_num description 1 1 4 4 7 8 102 111 112 113 203 baseball gloves baseball gloves football football basketball volleyball bicycle brakes 10-spd, assmbld 12-spd, assmbld 18-spd, assmbld irons/wedge unit unit_descr case case case case case case case each each each case 10 gloves/case 10 gloves/case 24/case 24/case 24/case 24/case 4 sets/case each each each 2 sets/case unit_price $800.00 $450.00 $960.00 $480.00 $600.00 $840.00 $480.00 $499.99 $549.00 $685.90 $670.00 (expression) $856.0000 $481.5000 $1027.2000 $513.6000 $642.0000 $898.8000 $513.6000 $534.9893 $587.4300 $733.9130 $716.9000
Query 2-38 calculates a surcharge of $6.50 on orders when the quantity ordered is less than 5:
Query 2-38
SELECT item_num, order_num, quantity, total_price, total_price + 6.50 FROM items WHERE quantity < 5
2-48
If you are using DB-Access or INFORMIX-SQL, the result appears in a column labeled expression, as shown in Query Result 2-38:
Query Result 2-38
item_num 1 1 2 1 2 1 2 3 4 . . . 1 2 3 4 1 2 3 1 2 3 4 5 6 1021 1021 1021 1021 1022 1022 1022 1023 1023 1023 1023 1023 1023 2 3 3 2 1 2 2 2 2 1 1 1 1 $75.00 $225.00 $690.00 $624.00 $40.00 $96.00 $96.00 $40.00 $116.00 $80.00 $228.00 $170.00 $190.00 $81.50 $231.50 $696.50 $630.50 $46.50 $102.50 $102.50 $46.50 $122.50 $86.50 $234.50 $176.50 $196.50 order_num quantity total_price 1001 1002 1002 1003 1003 1004 1004 1004 1004 1 1 1 1 1 1 1 1 1 $250.00 $960.00 $240.00 $20.00 $840.00 $250.00 $126.00 $240.00 $800.00 (expression) $256.50 $966.50 $246.50 $26.50 $846.50 $256.50 $132.50 $246.50 $806.50
Query 2-39 calculates and displays in an expression column (if you are using DB-Access or INFORMIX-SQL) the interval between when the customer call was received (call_dtime) and when the call was resolved (res_dtime), in days, hours, and minutes.
Query 2-39
SELECT customer_num, user_id, call_code, call_dtime, res_dtime - call_dtime FROM cust_calls ORDER BY user_id
2-49
Query Result 2-39

customer_num user_id 116 116 106 121 127 110 119 mannyn mannyn maryj maryj maryj richc richc call_code call_dtime I I D O I L B 1993-12-21 1993-11-28 1994-06-12 1994-07-10 1994-07-31 1994-07-07 1994-07-01 11:24 13:34 08:20 14:05 14:30 10:24 15:00 (expression) 5 0 0 0 20:55 03:13 00:05 00:01
0 00:06 0 17:21
Using Display Labels

You can assign a display label to a computed or derived data column to replace the default column header expression. In Query 2-40, Query 2-41, and Query 2-42, the derived data is shown in a column called (expression). Query 2-40 also presents derived values, but the column displaying the derived values now has the descriptive header, taxed.
Query 2-40
SELECT stock_num, description, unit, unit_descr, unit_price, unit_price * 1.07 taxed FROM stock WHERE unit_price >= 400
Query Result 2-40 shows the label taxed is assigned to the expression in the select list that displays the results of the operation unit_price * 1.07:
Query Result 2-40
stock_num description 1 1 4 4 7 8 102 111 112 113 203 baseball gloves baseball gloves football football basketball volleyball bicycle brakes 10-spd, assmbld 12-spd, assmbld 18-spd, assmbld irons/wedge unit unit_descr case case case case case case case each each each case 10 gloves/case 10 gloves/case 24/case 24/case 24/case 24/case 4 sets/case each each each 2 sets/case unit_price $800.00 $450.00 $960.00 $480.00 $600.00 $840.00 $480.00 $499.99 $549.00 $685.90 $670.00 taxed $856.0000 $481.5000 $1027.2000 $513.6000 $642.0000 $898.8000 $513.6000 $534.9893 $587.4300 $733.9130 $716.9000
2-50
In Query 2-41, the label surcharge is dened for the column that displays the results of the operation total_price + 6.50:
Query 2-41
SELECT item_num, order_num, quantity, total_price, total_price + 6.50 surcharge FROM items WHERE quantity < 5
The surcharge column is labeled in the output, as shown in Query Result 2-41:
Query Result 2-41
item_num . . . 2 3 4 1 2 1 1 2 3 4 1 2 . . . order_num quantity total_price surcharge
1013 1013 1013 1014 1014 1015 1016 1016 1016 1016 1017 1017
1 1 2 1 1 1 2 3 1 1 4 1
$36.00 $48.00 $40.00 $960.00 $480.00 $450.00 $136.00 $90.00 $308.00 $120.00 $150.00 $230.00
$42.50 $54.50 $46.50 $966.50 $486.50 $456.50 $142.50 $96.50 $314.50 $126.50 $156.50 $236.50
Query 2-42 assigns the label span to the column that displays the results of subtracting the DATETIME column call_dtime from the DATETIME column res_dtime.
Query 2-42
SELECT customer_num, user_id, call_code, call_dtime, res_dtime - call_dtime span FROM cust_calls ORDER BY user_id
2-51
The span column is labeled in the output, as shown in Query Result 2-42:
Query Result 2-42
customer_num user_id 116 116 106 121 127 110 119 mannyn mannyn maryj maryj maryj richc richc call_code call_dtime I I D O I L B 1993-12-21 1993-11-28 1994-06-12 1994-07-10 1994-07-31 1994-07-07 1994-07-01 11:24 13:34 08:20 14:05 14:30 10:24 15:00 span 5 0 0 0 20:55 03:13 00:05 00:01
0 00:06 0 17:21
Sorting on Derived Columns

When you want to use ORDER BY as an expression, you can use either the display label assigned to the expression or an integer, as shown in Query 2-43:
Query 2-43
SELECT customer_num, user_id, call_code, call_dtime, res_dtime - call_dtime span FROM cust_calls ORDER BY span
Query 2-43 retrieves the same data from the cust_calls table as Query 2-42. In Query 2-43, the ORDER BY clause causes the data to be displayed in ascending order of the derived values in the span column, as shown in Query Result 2-43:
customer_num user_id 127 121 106 110 116 119 116 maryj maryj maryj richc mannyn richc mannyn call_code call_dtime I O D L I B I 1994-07-31 1994-07-10 1994-06-12 1994-07-07 1992-11-28 1994-07-01 1992-12-21 14:30 14:05 08:20 10:24 13:34 15:00 11:24 span 0 0 0 0 0 5 00:01 00:05 00:06 03:13 17:21 20:55
Query Result 2-43
2-52
Using Functions in SELECT Statements
Query 2-44 uses an integer to represent the result of the operation res_dtime - call_dtime and retrieves the same rows that appear in Query Result 2-43.
Query 2-44
SELECT customer_num, user_id, call_code, call_dtime, res_dtime - call_dtime span FROM cust_calls ORDER BY 5

In addition to column names and operators, an expression can also include one or more functions. Expressions supported include aggregate, function (which include arithmetic functions), constant, and column expressions. These expressions are described in Chapter 1 of the Informix Guide to SQL: Syntax.
Aggregate Functions
The aggregate functions are COUNT, AVG, MAX, MIN, and SUM. They take on values that depend on all the rows selected and return information about rows, not the rows themselves. You cannot use these functions with TEXT or BYTE columns. Aggregates are often used to summarize information about groups of rows in a table. This use is discussed in Chapter 3, Composing Advanced SELECT Statements. When you apply an aggregate function to an entire table, the result contains a single row that summarizes all of the selected rows. Query 2-45 counts and displays the total number of rows in the stock table:
Query 2-45
SELECT COUNT(*) FROM stock
2-53
Query Result 2-45

(count(*)) 73
Query 2-46 includes a WHERE clause to count specic rows in the stock table; in this case, only those rows that have a manu_code of SHM:
Query 2-46
SELECT COUNT (*) FROM stock WHERE manu_code = 'SHM'
By including the keyword DISTINCT (or its synonym UNIQUE) and a column name in Query 2-47, you can tally the number of different manufacturer codes in the stock table:
Query 2-47
SELECT COUNT (DISTINCT manu_code) FROM stock
Query Result 2-47

(count) 9
Query 2-48 computes the average unit_price of all rows in the stock table:
Query 2-48
SELECT AVG (unit_price) FROM stock
Query Result 2-48

(avg) $197.14
2-54
Query 2-49 computes the average unit_price of just those rows in the stock table that have a manu_code of SHM:
Query 2-49
SELECT AVG (unit_price) FROM stock WHERE manu_code = 'SHM'
Query Result 2-49

(avg) $204.93
You can combine aggregate functions as shown in Query 2-50:

Query 2-50
SELECT MAX (ship_charge), MIN (ship_charge) FROM orders
Query 2-50 nds and displays both the highest and lowest ship_charge in the orders table, as shown in Query Result 2-50:
Query Result 2-50
(max) $25.20 (min) $5.00
You can apply functions to expressions, and you can supply display labels for their results, as shown in Query 2-51:
Query 2-51
SELECT MAX (res_dtime - call_dtime) maximum, MIN (res_dtime - call_dtime) minimum, AVG (res_dtime - call_dtime) average FROM cust_calls
2-55
Query 2-51 nds and displays the maximum, minimum, and average amount of time (in days, hours, and minutes) between the reception and resolution of a customer call and labels the derived values appropriately. These amounts of time are shown in Query Result 2-51:
Query Result 2-51
maximum 5 20:55 minimum 0 00:01 average 1 02:56
Query 2-52 calculates the total ship_weight of orders shipped on July 13, 1994:
Query 2-52
SELECT SUM (ship_weight) FROM orders WHERE ship_date = '07/13/1994'
Query Result 2-52

(sum) 130.5
Time Functions
You can use the time functions DAY, MDY, MONTH, WEEKDAY, YEAR, and DATE in either the SELECT clause or the WHERE clause of a query. These functions return a value that corresponds to the expressions or arguments that you use to call the function. You also can use the CURRENT function to return a value with the current date and time, or the EXTEND function to adjust the precision of a DATE or DATETIME value.
Using DAY and CURRENT

Query 2-53 returns the day of the month for the call_dtime and res_dtime columns in two expression columns, as shown in Query Result 2-53:
Query 2-53
SELECT customer_num, DAY (call_dtime), DAY (res_dtime) FROM cust_calls
2-56
Query Result 2-53

customer_num 106 110 119 121 127 116 116 (expression) (expression) 12 7 1 10 31 28 21 12 7 2 10 28 27
Query 2-54 uses the DAY and CURRENT functions to compare column values to the current day of the month. It selects only those rows where the value is earlier than the current day.
Query 2-54
SELECT customer_num, DAY (call_dtime), DAY (res_dtime) FROM cust_calls WHERE DAY (call_dtime) < DAY (CURRENT)
Query Result 2-54

customer_num 106 110 119 121 (expression) (expression) 12 7 1 10 12 7 2 10
Query 2-55 shows another use of the CURRENT function, selecting rows where the day is earlier than the current one:
Query 2-55
SELECT customer_num, call_code, call_descr FROM cust_calls WHERE call_dtime < CURRENT YEAR TO DAY
2-57
Query Result 2-55

customer_num call_code call_descr 106 D Order was received, but two of the cans of ANZ tennis balls within the case were empty 116 I Received plain white swim caps (313 ANZ) instead of navy with team logo (313 SHM) 116 I Second complaint from this customer! Received two cases right-handed outfielder gloves (1 HRO) instead of one case lefties.
customer_num call_code call_descr
customer_num call_code call_descr
Using MONTH
Query 2-56 uses the MONTH function to extract and show what month the customer call was received and resolved and uses display labels for the resulting columns. However, it does not make a distinction between years.
Query 2-56
SELECT customer_num, MONTH (call_dtime) call_month, MONTH (res_dtime) res_month FROM cust_calls
Query Result 2-56

customer_num 106 110 119 121 127 116 116 call_month 6 7 7 7 7 11 12 res_month 6 7 7 7 11 12
2-58
Query 2-57 uses the MONTH function plus DAY and CURRENT to show what month the customer call was received and resolved if DAY is earlier than the current day:
Query 2-57
SELECT customer_num, MONTH (call_dtime) called, MONTH (res_dtime) resolved FROM cust_calls WHERE DAY (res_dtime) < DAY (CURRENT)
Query Result 2-57

customer_num 106 119 121 called 6 7 7 resolved 6 7 7
Using WEEKDAY
In Query 2-58, the WEEKDAY function is used to indicate which day of the week calls are received and resolved (0 represents Sunday, 1 is Monday, and so on), and the expression columns are labeled:
Query 2-58
SELECT customer_num, WEEKDAY (call_dtime) called, WEEKDAY (res_dtime) resolved FROM cust_calls ORDER BY resolved
Query Result 2-58

customer_num 127 110 119 121 116 106 116 called 3 0 1 3 3 3 5 resolved
0 2 3 3 3 4
2-59
Query 2-59 uses the COUNT and WEEKDAY functions to count how many calls were received on a weekend. This kind of statement can give you an idea of customer call patterns or indicate whether overtime pay might be required.
Query 2-59
SELECT COUNT(*) FROM cust_calls WHERE WEEKDAY (call_dtime) IN (0,6)
(count(*)) 4
Query Result 2-59
Query 2-60 retrieves rows where the call_dtime is earlier than the beginning of the current year.
Query 2-60
SELECT customer_num, call_code, YEAR (call_dtime) call_year, YEAR (res_dtime) res_year FROM cust_calls WHERE YEAR (call_dtime) < YEAR (TODAY)
Query Result 2-60

customer_num call_code call_year res_year 116 I 116 I 1993 1993 1993 1993
Formatting DATETIME Values

In Query 2-61, the EXTEND function restricts the two DATETIME values by displaying only the specied subelds:
Query 2-61
SELECT customer_num, EXTEND (call_dtime, month to minute) call_time, EXTEND (res_dtime, month to minute) res_time FROM cust_calls ORDER BY res_time
2-60
Query Result 2-61 returns the month-to-minute range for the columns labeled call_time and res_time and gives an indication of the workload:
Query Result 2-61
customer_num call_time 127 106 119 110 121 116 116 07-31 06-12 07-01 07-07 07-10 11-28 12-21 14:30 08:20 15:00 10:24 14:05 13:34 11:24 res_time
06-12 07-02 07-07 07-10 11-28 12-27
08:25 08:21 10:30 14:06 16:47 08:19
Using the DATE Function

Query 2-62 retrieves DATETIME values only when call_dtime is later than the specied DATE:
Query 2-62
SELECT customer_num, call_dtime, res_dtime FROM cust_calls WHERE call_dtime > DATE ('12/31/93')
Query Result 2-62 returns the following rows:

Query Result 2-62
customer_num call_dtime 106 110 119 121 127 1994-06-12 1994-07-07 1994-07-01 1994-07-10 1994-07-31 08:20 10:24 15:00 14:05 14:30 res_dtime 1994-06-12 1994-07-07 1994-07-02 1994-07-10 08:25 10:30 08:21 14:06
2-61
Query 2-63 converts DATETIME values to DATE format and displays the values, with labels, only when call_dtime is greater than or equal to the specied date.
Query 2-63
SELECT customer_num, DATE (call_dtime) called, DATE (res_dtime) resolved FROM cust_calls WHERE call_dtime >= DATE ('1/1/94')
Query Result 2-63

customer_num called 106 110 119 121 127 06/12/1994 07/07/1994 07/01/1994 07/10/1994 07/31/1994 resolved 06/12/1994 07/07/1994 07/02/1994 07/10/1994
Other Functions and Keywords

You also can use the LENGTH, USER, CURRENT, and TODAY functions anywhere in an SQL expression that you would use a constant. In addition, with INFORMIX-OnLine Dynamic Server, you can include the DBSERVERNAME keyword in a SELECT statement to display the name of the database server where the current database resides. You can use these functions and keywords to select an expression that consists entirely of constant values or an expression that includes column data. In the rst instance, the result is the same for all rows of output. In addition, you can use the HEX function to return the hexadecimal encoding of an expression, the ROUND function to return the rounded value of an expression, and the TRUNC function to return the truncated value of an expression.
2-62
In Query 2-64, the LENGTH function calculates the number of bytes in the combined fname and lname columns for each row where the length of company is greater than 15:
Query 2-64
SELECT customer_num, LENGTH (fname) + LENGTH (lname) namelength FROM customer WHERE LENGTH (company) > 15
Query Result 2-64

customer_num 101 105 107 112 115 118 119 120 122 124 125 126 127 128 namelength 11 13 11 14 11 10 10 10 12 11 10 12 10 11
Although it might not be useful when you work with the DB-Access or INFORMIX-SQL ISED, the LENGTH function can be important to determine the string length for programs and reports. LENGTH returns the clipped length of a CHARACTER or VARCHAR string and the full number of bytes in a TEXT or BYTE string. The USER function can be handy when you want to dene a restricted view of a table that contains only your rows. For information on creating views, see Chapter 10, Granting and Limiting Access to Your Database, in this manual and the GRANT and CREATE VIEW statements in Chapter 1 of the Informix Guide to SQL: Syntax.
2-63
Query 2-65a species the USER function and the cust_calls table:
Query 2-65a
SELECT USER from cust_calls
Query 2-65b returns the user name (login account name) of the user who executes the query. It is repeated once for each row in the table.
Query 2-65b
SELECT * FROM cust_calls WHERE user_id = USER
If the user name of the current user is richc, Query 2-65b retrieves only those rows in the cust_calls table that are owned by that user, as shown in Query Result 2-65:
Query Result 2-65
customer_num call_dtime user_id call_code call_descr res_dtime res_descr 110 1994-07-07 10:24 richc L Order placed one month ago (6/7) not received. 1994-07-07 10:30 Checked with shipping (Ed Smith). Order sent yesterday- we were waiting for goods from ANZ. Next time will call with delay if necessary 119 1994-07-01 15:00 richc B Bill does not reflect credit from previous order 1994-07-02 08:21 Spoke with Jane Akant in Finance. She found the error and is sending new bill to customer
customer_num call_dtime user_id call_code call_descr res_dtime res_descr
2-64
Query 2-66, if issued when the current system date is July 10, 1994, returns this one row:
Query 2-66
SELECT * FROM orders WHERE order_date = TODAY
Query Result 2-66

order_num order_date customer_num ship_instruct backlog po_num ship_date ship_weight ship_charge paid_date 1018 07/10/1994 121 SW corner of Biltmore Mall n S22942 07/13/1994 70.50 $20.00 08/06/1994
You can include the keyword DBSERVERNAME (or its synonym, SITENAME) in a SELECT statement on INFORMIX-OnLine Dynamic Server to nd the name of the database server. You can query on the DBSERVERNAME for any table that has rows, including system catalog tables. In Query 2-67, you assign the label server to the DBSERVERNAME expression and also select the tabid column from the systables system catalog table. This table describes database tables, and tabid is the serial interval table identier.
Query 2-67
SELECT DBSERVERNAME server, tabid FROM systables WHERE tabid <= 4
Query Result 2-67

server montague montague montague montague tabid 1 2 3 4
2-65
Without the WHERE clause to restrict the values in the tabid, the database server name would be repeated for each row of the systables table. In Query 2-68, the HEX function returns the hexadecimal format of three specied columns in the customer table:
Query 2-68
SELECT HEX (customer_num) hexnum, HEX (zipcode) hexzip, HEX (rowid) hexrow FROM customer
Query Result 2-68

hexnum 0x00000065 0x00000066 0x00000067 0x00000068 0x00000069 0x0000006A 0x0000006B 0x0000006C 0x0000006D 0x0000006E 0x0000006F 0x00000070 0x00000071 0x00000072 0x00000073 0x00000074 0x00000075 0x00000076 0x00000077 0x00000078 0x00000079 0x0000007A 0x0000007B 0x0000007C 0x0000007D 0x0000007E 0x0000007F 0x00000080 hexzip 0x00016F86 0x00016FA5 0x0001705F 0x00016F4A 0x00016F46 0x00016F6F 0x00017060 0x00016F6F 0x00016F86 0x00016F6E 0x00016F85 0x00016F46 0x00016F49 0x00016F6E 0x00016F49 0x00016F58 0x00016F6F 0x00017191 0x00001F42 0x00014C18 0x00004DBA 0x0000215C 0x00007E00 0x00012116 0x00000857 0x0001395B 0x0000EBF6 0x00014C10 hexrow 0x00000001 0x00000002 0x00000003 0x00000004 0x00000005 0x00000006 0x00000007 0x00000008 0x00000009 0x0000000A 0x0000000B 0x0000000C 0x0000000D 0x0000000E 0x0000000F 0x00000010 0x00000011 0x00000012 0x00000013 0x00000014 0x00000015 0x00000016 0x00000017 0x00000018 0x00000019 0x0000001A 0x0000001B 0x0000001C
2-66
Using Stored Procedures in SELECT Statements

We have seen examples of SELECT statement expressions consisting of column names, operators, and functions. Another type of expression is one that contains a stored procedure call. Stored procedures are procedures that contain special Stored Procedure Language (SPL) statements as well as SQL statements. For more information on stored procedures, refer to Chapter 12, Creating and Using Stored Procedures. Stored procedures provide a way to extend the range of functions available; you can perform a subquery on each row you select. For example, suppose you want a listing of the customer number, the customers last name, and the number of orders the customer has made. One way to retrieve this information is shown in Query 2-69. The customer table has customer_num and lname columns but no record of the number of orders each customer has made. You could write a get_orders procedure, which queries the orders table for each customer_num and returns the number of corresponding orders (labeled n_orders).
Query 2-69
SELECT customer_num, lname, get_orders(customer_num) n_orders FROM customer
2-67
The output from this stored-procedure query is shown in Query Result 2-69:
Query Result 2-69
customer_num lname 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 Pauli Sadler Currie Higgins Vector Watson Ream Quinn Miller Jaeger Keyes Lawson Beatty Albertson Grant Parmelee Sipes Baxter Shorter Jewell Wallack OBrian Hanlon Putnum Henry Neelie Satifer Lessor n_orders 1 0 0 4 0 2 0 0 0 2 1 1 0 0 1 1 2 0 1 1 1 1 1 1 0 1 1 0
You can use stored procedures to encapsulate operations that you frequently perform in your queries. For example, the condition in Query 2-70 contains a procedure, conv_price, that converts the unit price of a stock item to a different currency and adds any import tariffs:
Query 2-70
SELECT stock_num, manu_code, description FROM stock WHERE conv_price(unit_price, ex_rate = 1.50, tariff = 50.00) < 1000
2-68
Multiple-Table SELECT Statements
Multiple-Table SELECT Statements

You can select data from two or more tables by naming these tables in the FROM clause. Add a WHERE clause to create a join condition between at least one related column in each table. This creates a temporary composite table in which each pair of rows that satises the join condition is linked to form a single row. A simple join combines information from two or more tables based on the relationship between one column in each table. A composite join is a join between two or more tables based on the relationship between two or more columns in each table. To create a join, you must specify a relationship, called a join condition, between at least one column from each table. Because the columns are being compared, they must have compatible data types. When you join large tables, performance improves when you index the columns in the join condition. Data types are described in Chapter 3 of the Informix Guide to SQL: Reference; indexing is discussed in detail in the administrators guide for your database server.
Creating a Cartesian Product

When you perform a multiple-table query that does not explicitly state a join condition among the tables, you create a Cartesian product. A Cartesian product consists of every possible combination of rows from the tables. This is usually a very large, unwieldy result, and the data is inaccurate. Query 2-71 selects from two tables and produces a Cartesian product:
Query 2-71
SELECT * FROM customer, state
2-69
Creating a Cartesian Product
Although only 52 rows exist in the state table and 28 rows in the customer table, the effect of Query 2-71 is to multiply the rows of one table by the rows of the other and retrieve an impractical 1,456 rows, as shown in Query 2-71:
customer_num fname lname company address1 address2 city state zipcode phone code sname customer_num fname lname company address1 address2 city state zipcode phone code sname customer_num fname lname company address1 address2 city state zipcode phone code sname . . . 101 Ludwig Pauli All Sports Supplies 213 Erstwild Court Sunnyvale CA 94086 408-789-8075 AK Alaska 101 Ludwig Pauli All Sports Supplies 213 Erstwild Court Sunnyvale CA 94086 408-789-8075 HI Hawaii 101 Ludwig Pauli All Sports Supplies 213 Erstwild Court Sunnyvale CA 94086 408-789-8075 CA California
Query Result 2-71
2-70
Creating a Join
Note that some of the data displayed in the concatenated rows is inaccurate. For example, although the city and state from the customer table indicate an address in California, the code and sname from the state table might be for a different state.
Creating a Join
Conceptually, the rst stage of any join is the creation of a Cartesian product. To rene or constrain this Cartesian product and eliminate meaningless rows of data, include a WHERE clause with a valid join condition in your SELECT statement. This section illustrates equi-joins, natural joins, and multiple-table joins. Additional complex forms, such as self-joins and outer joins, are covered in Chapter 3, Composing Advanced SELECT Statements.
Equi-Join
An equi-join is a join based on equality or matching values. This equality is indicated with an equal sign (=) in the comparison operation in the WHERE clause, as shown in Query 2-72:
Query 2-72
SELECT * FROM manufact, stock WHERE manufact.manu_code = stock.manu_code
2-71
Creating a Join
Query 2-72 joins the manufact and stock tables on the manu_code column, retrieving only those rows for which the values for the two columns are equal, as shown in Query Result 2-72:
Query Result 2-72
manu_code manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_code manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_code manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_code manu_name lead_time stock_num manu_code description unit_price unit unit_descr . . . SMT Smith 3 1 SMT baseball gloves $450.00 case 10 gloves/case SMT Smith 3 5 SMT tennis racquet $25.00 each each SMT Smith 3 6 SMT tennis ball $36.00 case 24 cans/case ANZ Anza 5 5 ANZ tennis racquet $19.80 each each
2-72
Creating a Join
Note that in this equi-join, Query Result 2-72 includes the manu_code column from both the manufact and stock tables because the select list requested every column. You also can create an equi-join with additional constraints, one where the comparison condition is based on the inequality of values in the joined columns. These joins use a relational operator other than the equal sign (=) in the comparison condition specied in the WHERE clause. When columns in the joined tables have the same name, the columns must be preceded by the name of a specic table and a period, as shown in Query 2-73:
Query 2-73
SELECT order_num, order_date, ship_date, cust_calls.* FROM orders, cust_calls WHERE call_dtime >= ship_date AND cust_calls.customer_num = orders.customer_num ORDER BY customer_num
2-73
Creating a Join
Query 2-73 joins on the customer_num column and then selects only those rows where the call_dtime in the cust_calls table is greater than or equal to the ship_date in the orders table. It returns the rows shown in Query Result 2-73:
Query Result 2-73
order_num order_date ship_date customer_num call_dtime user_id call_code call_descr res_dtime res_descr 1004 05/22/1994 05/30/1994 106 1994-06-12 08:20 maryj D Order received okay, but two of the cans of ANZ tennis balls within the case were empty 1994-06-12 08:25 Authorized credit for two cans to customer, issued apology. Called ANZ buyer to report the qa problem. 1008 06/07/1994 07/06/1994 110 1994-07-07 10:24 richc L Order placed one month ago (6/7) not received. 1994-07-07 10:30 Checked with shipping (Ed Smith). Order out yesterday-was waiting for goods from ANZ. Next time will call with delay if necessary. 1023 07/24/1994 07/30/1994 127 1994-07-31 14:30 maryj I Received Hero watches (item # 304) instead of ANZ watches Sent memo to shipping to send ANZ item 304 to customer and pickup HRO watches. Should be done tomorrow, 8/1
order_num order_date ship_date customer_num call_dtime user_id call_code call_descr res_dtime res_descr
order_num order_date ship_date customer_num call_dtime user_id call_code call_descr res_dtime res_descr
2-74
Creating a Join Natural Join

A natural join is structured so that the join column does not display data redundantly, as shown in Query 2-74:
Query 2-74
SELECT manu_name, lead_time, stock.* FROM manufact, stock WHERE manufact.manu_code = stock.manu_code
Like the example for equi-join, Query 2-74 joins the manufact and stock tables on the manu_code column. Because the select list is more closely dened, the manu_code is listed only once for each row retrieved, as shown in Query Result 2-74.
2-75
Creating a Join
Query Result 2-74

manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_name lead_time stock_num manu_code description unit_price unit unit_descr manu_name lead_time stock_num manu_code description unit_price unit unit_descr . . . Smith 3 1 SMT baseball gloves $450.00 case 10 gloves/case Smith 3 5 SMT tennis racquet $25.00 each each Smith 3 6 SMT tennis ball $36.00 case 24 cans/case Anza 5 5 ANZ tennis racquet $19.80 each each
All joins are associative, that is, the order of the joining terms in the WHERE clause does not affect the meaning of the join.
2-76
Creating a Join
Both of the statements in Query 2-75 create the same natural join:
Query 2-75
SELECT catalog.*, description, unit_price, unit, unit_descr FROM catalog, stock WHERE catalog.stock_num = stock.stock_num AND catalog.manu_code = stock.manu_code AND catalog_num = 10017 SELECT catalog.*, description, unit_price, unit, unit_descr FROM catalog, stock WHERE catalog_num = 10017 AND catalog.manu_code = stock.manu_code AND catalog.stock_num = stock.stock_num
Each statement retrieves the row shown in Query Result 2-75:

Query Result 2-75
catalog_num 10017 stock_num 101 manu_code PRC cat_descr Reinforced, hand-finished tubular. Polyurethane belted. Effective against punctures. Mixed tread for super wear and road grip. cat_picture <BYTE value> cat_advert description unit_price unit unit_descr Ultimate in Puncture Protection, Tires Designed for In-City Riding bicycle tires $88.00 box 4/box
Note that Query 2-75 includes a TEXT column, cat_descr; a BYTE column, cat_picture; and a VARCHAR column, cat_advert.
2-77
Creating a Join Multiple-Table Join

A multiple-table join connects more than two tables on one or more associated columns; it can be an equi-join or a natural join. Query 2-76 creates an equi-join on the catalog, stock, and manufact tables and retrieves the following row:
Query 2-76
SELECT * FROM catalog, stock, manufact WHERE catalog.stock_num = stock.stock_num AND stock.manu_code = manufact.manu_code AND catalog_num = 10025
Query 2-76 retrieves the rows shown in Query Result 2-76:

Query Result 2-76
catalog_num 10025 stock_num 106 manu_code PRC cat_descr Hard anodized alloy with pearl finish; 6mm hex bolt hardware. Available in lengths of 90-140mm in 10mm increments. cat_picture <BYTE value> cat_advert stock_num manu_code description unit_price unit unit_descr manu_code manu_name lead_time ProCycle Stem with Pearl Finish 106 PRC bicycle stem $23.00 each each PRC ProCycle 9
Note that the manu_code is repeated three times, once for each table, and stock_num is repeated twice.
2-78
Creating a Join
Because of the considerable duplication of a multiple-table query in Query 2-76, it is wise to more closely dene the SELECT statement by including specic columns in the select list, as shown in Query 2-77:
Query 2-77
SELECT catalog.*, description, unit_price, unit, unit_descr, manu_name, lead_time FROM catalog, stock, manufact WHERE catalog.stock_num = stock.stock_num AND stock.manu_code = manufact.manu_code AND catalog_num = 10025
Query 2-77 uses a wildcard to select all columns from the table having the most columns and then species columns from the other two tables. It produces the natural join, shown in Query Result 2-77, that displays the same information as the previous example, but without duplication:
Query Result 2-77
catalog_num 10025 stock_num 106 manu_code PRC cat_descr Hard anodized alloy with pearl finish. 6mm hex bolt hardware. Available in lengths of 90-140mm in 10mm increments. cat_picture <BYTE value> cat_advert description unit_price unit unit_descr manu_name lead_time ProCycle Stem with Pearl Finish bicycle stem $23.00 each each ProCycle 9
2-79
Some Query Shortcuts

You can use aliases, the INTO TEMP clause, and display labels to speed your way through joins and multiple-table queries and to produce output for other uses.
Using Aliases
You can make multiple-table queries shorter and more readable by assigning aliases to the tables in a SELECT statement. An alias is a word that immediately follows the name of a table in the FROM clause. You can use it wherever the table name would be used, for instance, as a prex to the column names in the other clauses.
Query 2-78a
SELECT s.stock_num, s.manu_code, s.description, s.unit_price, s.unit, c.catalog_num, c.cat_descr, c.cat_advert, m.lead_time FROM stock s, catalog c, manufact m WHERE s.stock_num = c.stock_num AND s.manu_code = c.manu_code AND s.manu_code = m.manu_code AND s.manu_code IN ('HRO', 'HSK') AND s.stock_num BETWEEN 100 AND 301 ORDER BY catalog_num
The associative nature of the SELECT statement allows you to use an alias before you dene it. In Query 2-78a, the aliases s for the stock table, c for the catalog table, and m for the manufact table are specied in the FROM clause and used throughout the SELECT and WHERE clauses as column prexes. Compare the length of Query 2-78a with Query 2-78b, which does not use aliases:
Query 2-78b
SELECT stock.stock_num, stock.manu_code, stock.description, stock.unit_price, stock.unit, catalog.catalog_num, catalog.cat_descr, catalog.cat_advert, manufact.lead_time FROM stock, catalog, manufact WHERE stock.stock_num = catalog.stock_num AND stock.manu_code = catalog.manu_code AND stock.manu_code = manufact.manu_code AND stock.manu_code IN ('HRO', 'HSK') AND stock.stock_num BETWEEN 100 AND 301 ORDER BY catalog_num
2-80
Query 2-78a and Query 2-78b are equivalent and retrieve the data shown in Query Result 2-78:
Query Result 2-78
stock_num 110 manu_code HRO description helmet unit_price $260.00 unit case catalog_num 10033 cat_descr Newest ultralight helmet uses plastic shell. Largest ventilation channels of any helmet on the market. 8.5 oz. cat_advert Lightweight Plastic Slatted with Vents Assures Cool Comfort Without Sacrificing Protection lead_time 4 stock_num 110 manu_code HSK description helmet unit_price $308.00 unit each catalog_num 10034 cat_descr Aerodynamic (teardrop) helmet covered with anti-drag fabric. Credited with shaving 2 seconds/mile from winners time in Tour de France time-trial. 7.5 oz. cat_advert Teardrop Design Endorsed by Yellow Jerseys, You Can Time the Difference lead_time 5 stock_num 205 manu_code HRO description 3 golf balls unit_price $312.00 unit each catalog_num 10048 cat_descr Combination fluorescent yellow and standard white. cat_advert HiFlier Golf Balls: Case Includes Fluorescent Yellow and Standard White lead_time 4 stock_num 301 manu_code HRO description running shoes unit_price $42.50 unit each catalog_num 10050 cat_descr Engineered for serious training with exceptional stability. Fabulous shock absorption. Great durability. Specify mens/womens, size. cat_advert Pronators and Supinators Take Heart: A Serious Training Shoe For Runners Who Need Motion Control lead_time 4
2-81
Note that you cannot ORDER BY the TEXT column cat_descr or the BYTE column cat_picture. You also can use aliases to shorten your queries on external tables residing in external databases. Query 2-79 joins columns from two tables that reside in different databases and systems, neither of which is the current database or system:
Query 2-79
SELECT order_num, lname, fname, phone FROM masterdb@central:customer c, sales@western:orders o WHERE c.customer_num = o.customer_num AND order_num <= 1010
By assigning the aliases c and o to the long database@system:table names, masterdb@central:customer and sales@western:orders, respectively, you can use the aliases to shorten the expression in the WHERE clause and retrieve the data shown in Query Result 2-79:
Query Result 2-79
order_num lname fname phone
1001 1002 1003 1004 1005 1006 1007 1008 1009 1010
Higgins Pauli Higgins Watson Parmelee Lawson Sipes Jaeger Keyes Grant
Anthony Ludwig Anthony George Jean Margaret Arnold Roy Frances Alfred
415-368-1100 408-789-8075 415-368-1100 415-389-8789 415-534-8822 415-887-7235 415-245-4578 415-743-3611 408-277-7245 415-356-1123
For more information on external tables and external databases, see Chapter 11, Understanding Informix Networking, in this manual and Chapter 1 in the Informix Guide to SQL: Syntax. You also can use synonyms as shorthand references to the long names of external and current tables and views. For details on how to create and use synonyms, see Chapter 11, Understanding Informix Networking, in this manual and the CREATE SYNONYM statement in Chapter 1 of the Informix Guide to SQL: Syntax.
Some Query Shortcuts The INTO TEMP Clause

By adding an INTO TEMP clause to your SELECT statement, you can temporarily save the results of a multiple-table query in a separate table that can be queried or manipulated without modifying the database. Temporary tables are dropped when you end your SQL session or when your program or report terminates. Query 2-80 creates a temporary table called stockman and stores the results of the query in it. Because all columns in a temporary table must have names, the alias adj_price is required.
Query 2-80
SELECT DISTINCT stock_num, manu_name, description, unit_price, unit_price * 1.05 adj_price FROM stock, manufact WHERE manufact.manu_code = stock.manu_code INTO TEMP stockman
Query Result 2-80

stock_num manu_name 1 1 1 2 3 4 4 . . . 306 307 308 309 309 310 310 311 312 312 313 313 Hero Husky Smith Hero Husky Hero Husky description baseball baseball baseball baseball baseball football football gloves gloves gloves bat unit_price $250.00 $800.00 $450.00 $126.00 $240.00 $480.00 $960.00 adj_price $262.5000 $840.0000 $472.5000 $132.3000 $252.0000 $504.0000 $1008.0000
Shimara ProCycle ProCycle Hero Shimara Anza Shimara Shimara Hero Shimara Anza Shimara
tandem adapter infant jogger twin jogger ear drops ear drops kick board kick board water gloves racer goggles racer goggles swim cap swim cap
$190.00 $250.00 $280.00 $40.00 $40.00 $84.00 $80.00 $48.00 $72.00 $96.00 $60.00 $72.00
$199.5000 $262.5000 $294.0000 $42.0000 $42.0000 $88.2000 $84.0000 $50.4000 $75.6000 $100.8000 $63.0000 $75.6000
You can query on this table and join it with other tables, which avoids a multiple sort and lets you move more quickly through the database. Temporary tables are discussed at greater length in the INFORMIX-OnLine Dynamic Server Administrators Guide.
Composing Simple SELECT Statements 2-83
Summary
Summary
This chapter introduced sample syntax and results for basic kinds of SELECT statements that are used to query on a relational database. Earlier sections of the chapter showed how to perform the following activities:
s
Select all columns and rows from a table with the SELECT and FROM clauses Select specic columns from a table with the SELECT and FROM clauses Select specic rows from a table with the SELECT, FROM, and WHERE clauses Use the DISTINCT or UNIQUE keyword in the SELECT clause to eliminate duplicate rows from query results Sort retrieved data with the ORDER BY clause and the DESC keyword Select and order data containing foreign characters Use the BETWEEN, IN, MATCHES, and LIKE keywords and various relational operators in the WHERE clause to create a comparison condition Create comparison conditions that include values, exclude values, nd a range of values (with keywords, relational operators, and subscripting), and nd a subset of values Perform variable text searches using exact text comparisons, variable-length wildcards, and restricted and unrestricted wildcards Use the logical operators AND, OR, and NOT to connect search conditions or Boolean expressions in a WHERE clause Use the ESCAPE keyword to protect special characters in a query Search for null values with the IS NULL and IS NOT NULL keywords in the WHERE clause Use arithmetic operators in the SELECT clause to perform computations on number elds and display derived data Use substrings and subscripting to tailor your queries Assign display labels to computed columns as a formatting tool for reports
s s s
s s
s s
2-84
Summary
Use the aggregate functions COUNT, AVG, MAX, MIN, and SUM in the SELECT clause to calculate and retrieve specic data Include the time functions DATE, DAY, MDY, MONTH, WEEKDAY, YEAR, CURRENT, and EXTEND plus the TODAY, LENGTH, and USER functions in your SELECT statements Include stored procedures in your SELECT statements
This chapter also introduced simple join conditions that enable you to select and display data from two or more tables. The section Multiple-Table SELECT Statements on page 2-69 described how to perform the following actions:
s s
Create a Cartesian product Constrain a Cartesian product by including a WHERE clause with a valid join condition in your query Dene and create a natural join and an equi-join Join two or more tables on one or mxore columns Use aliases as a shortcut in multiple-table queries Retrieve selected data into a separate, temporary table with the INTO TEMP clause to perform computations outside the database.
s s s s
The next chapter explains more complex queries and subqueries; self-joins and outer joins; the GROUP BY and HAVING clauses; and the UNION, INTERSECTION, and DIFFERENCE set operations.
2-85
Chapter
Composing Advanced SELECT Statements

Using the GROUP BY and HAVING Clauses . Using the GROUP BY Clause . . . . . Using the HAVING Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 3-4 3-8 3-11 3-11 3-21 3-22 3-24 3-26 3-27 3-29 3-31 3-33 3-34 3-35 3-36 3-37 3-41 3-42 3-50 3-52 3-54
Creating Advanced Joins . . . . . . . . . . Self-Joins . . . . . . . . . . . . . . Outer Joins . . . . . . . . . . . . . Simple Join . . . . . . . . . . . . Simple Outer Join on Two Tables . . . . Outer Join for a Simple Join to a Third Table Outer Join for an Outer Join to a Third Table Outer Join of Two Tables to a Third Table . Subqueries in SELECT Statements Using ALL . . . . . . . Using ANY . . . . . . . Single-Valued Subqueries . . Correlated Subqueries . . . Using EXISTS . . . . . . Set Operations Union . . Intersection Difference. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-2
he previous chapter Composing Simple SELECT Statements, demonstrated some basic ways to retrieve data from a relational database with the SELECT statement. This chapter increases the scope of what you can do with this powerful SQL statement and enables you to perform more complex database queries and data manipulation. Whereas the previous chapter focused on ve of the clauses in SELECT statement syntax, this chapter adds two more. You can use the GROUP BY clause with aggregate functions to organize rows returned by the FROM clause. You can include a HAVING clause to place conditions on the values returned by the GROUP BY clause. This chapter extends the earlier discussion of joins. It illustrates self-joins, which enable you to join a table to itself, and four kinds of outer joins, where you apply the keyword OUTER to treat two or more joined tables unequally. It also introduces correlated and uncorrelated subqueries and their operational keywords, shows how to combine queries with the UNION operator, and denes the set operations known as union, intersection, and difference. Examples in this chapter show how to use some or all of the SELECT statement clauses in your queries. The clauses must appear in the following order:
1. 2. 3. 4. 5. 6. 7. SELECT FROM WHERE GROUP BY HAVING ORDER BY INTO TEMP
Composing Advanced SELECT Statements 3-3
Using the GROUP BY and HAVING Clauses
An additional SELECT statement clause, INTO, which you can use to specify program and host variables in INFORMIX-4GL and SQL APIs is described in Chapter 5, Programming with SQL, as well as in the manuals that come with the product.
Using the GROUP BY and HAVING Clauses

The optional GROUP BY and HAVING clauses add functionality to your SELECT statement. You can include one or both in a basic SELECT statement to increase your ability to manipulate aggregates. The GROUP BY clause combines similar rows, producing a single result row for each group of rows that have the same values for each column listed in the select list. The HAVING clause sets conditions on those groups after you form them. You can use a GROUP BY clause without a HAVING clause, or a HAVING clause without a GROUP BY clause.
Using the GROUP BY Clause

The GROUP BY clause divides a table into sets. It is most often combined with aggregate functions that produce summary values for each of those sets. Some examples in Chapter 2, Composing Simple SELECT Statements show the use of aggregate functions applied to a whole table. This chapter illustrates aggregate functions applied to groups of rows. Using the GROUP BY clause without aggregates is much like using the DISTINCT (or UNIQUE) keyword in the SELECT clause. Chapter 2, Composing Simple SELECT Statements included the statement found in Query 3-1a:
Query 3-1a
SELECT DISTINCT customer_num FROM orders
You also could write the statement as shown in Query 3-1b:

Query 3-1b
SELECT customer_num FROM orders GROUP BY customer_num
3-4
Query 3-1a and Query 3-1b return the rows shown in Query Result 3-1:
Query Result 3-1
customer_num 101 104 106 110 111 112 115 116 117 119 120 121 122 123 124 126 127
The GROUP BY clause collects the rows into sets so that each row in each set has equal customer numbers. With no other columns selected, the result is a list of the unique customer_num values. The power of the GROUP BY clause is more apparent when you use it with aggregate functions. Query 3-2 retrieves the number of items and the total price of all items for each order:
Query 3-2
SELECT order_num, COUNT (*) number, SUM (total_price) price FROM items GROUP BY order_num
The GROUP BY clause causes the rows of the items table to be collected into groups, each group composed of rows that have identical order_num values (that is, the items of each order are grouped together). After you form the groups, the aggregate functions COUNT and SUM are applied within each group.
Query 3-2 returns one row for each group. It uses labels to give names to the results of the COUNT and SUM expressions, as shown in Query Result 3-2:
Query Result 3-2
order_num 1001 1002 1003 1004 1005 1006 1007 1008 . . . 1015 1016 1017 1018 1019 1020 1021 1022 1023 number 1 2 3 4 4 5 5 2 price $250.00 $1200.00 $959.00 $1416.00 $562.00 $448.00 $1696.00 $940.00
1 4 3 5 1 2 4 3 6
$450.00 $654.00 $584.00 $1131.00 $1499.97 $438.00 $1614.00 $232.00 $824.00
Query Result 3-2 collects the rows of the items table into groups that have identical order numbers and computes the COUNT of rows in each group and the sum of the prices. Note that you cannot include a column having a TEXT or BYTE data type in a GROUP BY clause. To group, you must be able to sort, and no natural sort order exists for TEXT or BYTE data. Unlike the ORDER BY clause, the GROUP BY clause does not order data. Include an ORDER BY clause after your GROUP BY clause if you want to sort data in a particular order or to sort on an aggregate in the select list.
3-6
Query 3-3 is the same as Query 3-2 but includes an ORDER BY clause to sort the retrieved rows in ascending order of price, as shown in Query Result 3-3:
Query 3-3
SELECT order_num, COUNT(*) number, SUM (total_price) price FROM items GROUP BY order_num ORDER BY price
Query Result 3-3

order_num 1010 1011 1013 1022 1001 1020 1006 1015 1009 . . . 1018 1002 1004 1014 1019 1021 1007 number 2 1 4 3 1 2 5 1 1 price $84.00 $99.00 $143.80 $232.00 $250.00 $438.00 $448.00 $450.00 $450.00
5 2 4 2 1 4 5
$1131.00 $1200.00 $1416.00 $1440.00 $1499.97 $1614.00 $1696.00
As stated in Chapter 2, Composing Simple SELECT Statements, you can use an integer in an ORDER BY clause to indicate the position of a column in the select list. You also can use an integer in a GROUP BY clause to indicate the position of column names or display labels in the group list. Query 3-4 returns the same rows as Query 3-3, as shown in Query Result 3-3.
Query 3-4
SELECT order_num, COUNT(*) number, SUM (total_price) price FROM items GROUP BY 1 ORDER BY 3
Using the HAVING Clause
When you build a query, remember that all nonaggregate columns that are in the select list in the SELECT clause must also be included in the group list in the GROUP BY clause. The reason for this is that a SELECT with GROUP BY must return only one row per group. Columns that are listed after GROUP BY are certain to reect only one distinct value within a group, and that value can be returned. However, a column not listed after GROUP BY might contain different values in the rows that are contained in a group. As shown in Query 3-5, you can use the GROUP BY clause in a SELECT statement that joins tables:
Query 3-5
SELECT o.order_num, SUM (i.total_price) FROM orders o, items i WHERE o.order_date > '01/01/93' AND o.customer_num = 110 AND o.order_num = i.order_num GROUP BY o.order_num
Query 3-5 joins the orders and items tables, assigns table aliases to them, and returns the rows shown in Query Result 3-5:
Query Result 3-5
order_num 1008 1015 (sum) $940.00 $450.00

The HAVING clause usually complements a GROUP BY clause by applying one or more qualifying conditions to groups after they are formed, which is similar to the way the WHERE clause qualies individual rows. One advantage to using a HAVING clause is that you can include aggregates in the search condition, whereas you cannot include aggregates in the search condition of a WHERE clause. Each HAVING condition compares one column or aggregate expression of the group with another aggregate expression of the group or with a constant. You can use HAVING to place conditions on both column values and aggregate values in the group list.
3-8
Query 3-6 returns the average total price per item on all orders that have more than two items. The HAVING clause tests each group as it is formed and selects those composed of two or more rows.
Query 3-6
SELECT order_num, COUNT(*) number, AVG (total_price) average FROM items GROUP BY order_num HAVING COUNT(*) > 2
Query Result 3-6

order_num 1003 1004 1005 1006 1007 1013 1016 1017 1018 1021 1022 1023 number 3 4 4 5 5 4 4 3 5 4 3 6 average $319.67 $354.00 $140.50 $89.60 $339.20 $35.95 $163.50 $194.67 $226.20 $403.50 $77.33 $137.33
If you use a HAVING clause without a GROUP BY clause, the HAVING condition applies to all rows that satisfy the search condition. In other words, all rows that satisfy the search condition make up a single group. Query 3-7, a modied version of Query 3-6, returns just one row, the average of all total_price values in the table:
Query 3-7
SELECT AVG (total_price) average FROM items HAVING count(*) > 2
Query Result 3-7

average $270.97
If Query 3-7, like Query 3-6, had included the nonaggregate column order_ num in the select list, you would have to include a GROUP BY clause with that column in the group list. In addition, if the condition in the HAVING clause was not satised, the output would show the column heading and a message would indicate that no rows were found. Query 3-8 contains all the SELECT statement clauses that you can use in the Informix version of interactive SQL (the INTO clause naming program or host variables is available only in an INFORMIX-4GL or an SQL API):
Query 3-8
SELECT o.order_num, SUM (i.total_price) price, paid_date - order_date span FROM orders o, items i WHERE o.order_date > '01/01/93' AND o.customer_num > 110 AND o.order_num = i.order_num GROUP BY 1, 3 HAVING COUNT (*) < 5 ORDER BY 3 INTO TEMP temptab1
Query 3-8 joins the orders and items tables; employs display labels, table aliases, and integers used as column indicators; groups and orders the data; and puts the following results in a temporary table, as shown in Query Result 3-8:
Query Result 3-8
order_num 1017 1016 1012 1019 1005 1021 1022 1010 1009 1020 price $584.00 $654.00 $1040.00 $1499.97 $562.00 $1614.00 $232.00 $84.00 $450.00 $438.00 span
26 28 30 40 66 68 71
3-10
Creating Advanced Joins
Creating Advanced Joins

Chapter 2, Composing Simple SELECT Statements, showed how to include a WHERE clause in a SELECT statement to join two or more tables on one or more columns. It illustrated natural joins and equi-joins. This chapter discusses the uses of two more complex kinds of joins: self-joins and outer joins. As described for simple joins, you can dene aliases for tables and assign display labels to expressions to shorten your multiple-table queries. You can also sort data with an ORDER BY clause and SELECT query results into a temporary table.
Self-Joins
A join does not always have to involve two different tables. You can join a table to itself, creating a self-join. This can be useful when you want to compare values in a column to other values in the same column. To create a self-join, list a table twice in the FROM clause, assigning it a different alias each time. Use the aliases to refer to the table in the SELECT and WHERE clauses as if it were two separate tables. (Aliases in SELECT statements are shown in Chapter 2, Composing Simple SELECT Statements, in this manual and discussed in Chapter 1 of the Informix Guide to SQL: Syntax.) Just as in joins between tables, you can use arithmetic expressions in self-joins. You can test for null values, and you can ORDER BY a specied column in ascending or descending order. Query 3-9 nds pairs of orders where the ship_weight differs by a factor of ve or more, and the ship_date is not null and orders the data by ship_date:
Query 3-9
SELECT x.order_num, x.ship_weight, x.ship_date, y.order_num, y.ship_weight, y.ship_date FROM orders x, orders y WHERE x.ship_weight >= 5 * y.ship_weight AND x.ship_date IS NOT NULL AND y.ship_date IS NOT NULL ORDER BY x.ship_date
Self-Joins
Query Result 3-9

order_num ship_weight ship_date 1004 1004 1004 1007 1007 1007 1007 1007 1007 1005 1005 1005 1012 1012 1013 1017 1018 . . . 95.80 95.80 95.80 125.90 125.90 125.90 125.90 125.90 125.90 80.80 80.80 80.80 70.80 70.80 60.80 60.00 70.50 05/30/1994 05/30/1994 05/30/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/09/1994 06/09/1994 06/09/1994 06/29/1994 06/29/1994 07/10/1994 07/13/1994 07/13/1994 order_num ship_weight ship_date 1011 1020 1022 1015 1020 1022 1011 1001 1009 1011 1020 1022 1011 1020 1011 1011 1011 10.40 14.00 15.00 20.60 14.00 15.00 10.40 20.40 20.40 10.40 14.00 15.00 10.40 14.00 10.40 10.40 10.40 07/03/1994 07/16/1994 07/30/1994 07/16/1994 07/16/1994 07/30/1994 07/03/1994 06/01/1994 06/21/1994 07/03/1994 07/16/1994 07/30/1994 07/03/1994 07/16/1994 07/03/1994 07/03/1994 07/03/1994
Suppose you want to select the results of a self-join into a temporary table. You would, of course, append an INTO TEMP clause to the SELECT statement. However, because you are, in effect, creating a new table, you also must rename at least one set of column names by assigning them display labels. Otherwise, you get an error message that indicates duplicate column names, and the temporary table is not created. Query 3-10, which is similar to Query 3-9, labels all columns selected from the orders table and puts them in a temporary table called shipping:
Query 3-10
SELECT x.order_num orders1, x.po_num purch1, x.ship_date ship1, y.order_num orders2, y.po_num purch2, y.ship_date ship2 FROM orders x, orders y WHERE x.ship_weight >= 5 * y.ship_weight AND x.ship_date IS NOT NULL AND y.ship_date IS NOT NULL ORDER BY orders1, orders2 INTO TEMP shipping
If you SELECT * from that table, you see the rows in Query Result 3-10:
3-12
Self-Joins
Query Result 3-10

orders1 purch1 1004 1004 1004 1005 1005 1005 1007 1007 1007 1007 1007 1007 1012 1012 1013 1017 1018 1018 1019 1019 1019 1023 8006 8006 8006 2865 2865 2865 278693 278693 278693 278693 278693 278693 278701 278701 B77930 DM354331 S22942 S22942 Z55709 Z55709 Z55709 KF2961 ship1 05/30/1994 05/30/1994 05/30/1994 06/09/1994 06/09/1994 06/09/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/05/1994 06/29/1994 06/29/1994 07/10/1994 07/13/1994 07/13/1994 07/13/1994 07/16/1994 07/16/1994 07/16/1994 07/30/1994 orders2 purch2 1011 1020 1022 1011 1020 1022 1001 1009 1011 1015 1020 1022 1011 1020 1011 1011 1011 1020 1011 1020 1022 1011 B77897 W2286 W9925 B77897 W2286 W9925 B77836 4745 B77897 MA003 W2286 W9925 B77897 W2286 B77897 B77897 B77897 W2286 B77897 W2286 W9925 B77897 ship2 07/03/1994 07/16/1994 07/30/1994 07/03/1994 07/16/1994 07/30/1994 06/01/1994 06/21/1994 07/03/1994 07/16/1994 07/16/1994 07/30/1994 07/03/1994 07/16/1994 07/03/1994 07/03/1994 07/03/1994 07/16/1994 07/03/1994 07/16/1994 07/30/1994 07/03/1994
You can join a table to itself more than once. The maximum number of self-joins depends on the resources available to you. The self-join in Query 3-11 creates a list of those items in the stock table that are supplied by three manufacturers. By including the last two conditions in the WHERE clause, it eliminates duplicate manufacturer codes in rows retrieved.
Query 3-11
SELECT s1.manu_code, s2.manu_code, s3.manu_code, s1.stock_num, s1.description FROM stock s1, stock s2, stock s3 WHERE s1.stock_num = s2.stock_num AND s2.stock_num = s3.stock_num AND s1.manu_code < s2.manu_code AND s2.manu_code < s3.manu_code ORDER BY stock_num
Self-Joins
Query Result 3-11

manu_code manu_code manu_code stock_num description HRO ANZ ANZ ANZ ANZ ANZ ANZ ANZ HRO HRO HRO HSK ANZ ANZ ANZ . . . HRO KAR KAR KAR NKL HSK NRG HRO HRO HRO HSK HSK PRC HSK HSK PRC PRC KAR HRO HRO SMT SMT HSK PRC SHM PRC SHM SHM PRC SHM SHM SHM NKL NKL KAR 1 5 110 110 110 110 110 110 110 110 110 110 201 205 301 baseball gloves tennis racquet helmet helmet helmet helmet helmet helmet helmet helmet helmet helmet golf shoes 3 golf balls running shoes
PRC NKL NKL PRC PRC
SHM PRC SHM SHM SHM
301 301 301 301 301
running running running running running
shoes shoes shoes shoes shoes
Say you want to select rows from a payroll table to determine which employees earn more than their manager. You can construct the self-join shown in Query 3-12a:
Query 3-12a
SELECT emp.employee_num, emp.gross_pay, emp.level, emp.dept_num, mgr.employee_num, mgr.gross_pay, mgr.dept_num, mgr.level FROM payroll emp, payroll mgr WHERE emp.gross_pay > mgr.gross_pay AND emp.level < mgr.level AND emp.dept_num = mgr.dept_num ORDER BY 4
3-14
Self-Joins
Query 3-12b uses a correlated subquery to retrieve and list the 10 highestpriced items ordered:
Query 3-12b
SELECT order_num, total_price FROM items a WHERE 10 > (SELECT COUNT (*) FROM items b WHERE b.total_price < a.total_price) ORDER BY total_price
Query 3-12b returns the 10 rows shown in Query Result 3-12:

Query Result 3-12
order_num total_price 1018 1013 1003 1005 1006 1013 1010 1013 1022 1023 $15.00 $19.80 $20.00 $36.00 $36.00 $36.00 $36.00 $40.00 $40.00 $40.00
You can create a similar query to nd and list the 10 employees in the company who have the most seniority. Correlated and uncorrelated subqueries are described later in Subqueries in SELECT Statements on page 3-31.
Using Rowid Values

Important: OnLine assigns a unique rowid to rows in nonfragmented tables. Rows in fragmented tables do not contain the rowid column. Informix recommends that you use primary keys as a method of access in your applications rather than rowids. Because primary keys are dened in the ANSI specication of SQL, using them to access data makes your applications more portable. In addition, the time required by OnLine to access data in a fragmented table using a primary key is less than the time required to access the same data using rowid. For additional information about rowids and tables, see Accessing Data Stored in Fragmented Tables on page 9-41.
Self-Joins
You can use the hidden rowid column in a self-join to locate duplicate values in a table. In the following example, the condition x.rowid != y.rowid is equivalent to saying row x is not the same row as row y. Query 3-13 selects data twice from the cust_calls table, assigning it the table aliases x and y:
Query 3-13
SELECT x.rowid, x.customer_num FROM cust_calls x, cust_calls y WHERE x.customer_num = y.customer_num AND x.rowid != y.rowid
Query 3-13 searches for duplicate values in the customer_num column, and for their rowids, nding the pair shown in Query Result 3-13:
Query Result 3-13
rowid customer_num 515 769 116 116
You can write the last condition in Query 3-13 as shown in the following example:
AND x.rowid != y.rowid AND NOT x.rowid = y.rowid
Another way to locate duplicate values is with a correlated subquery, as shown in Query 3-14:
Query 3-14
SELECT x.customer_num, x.call_dtime FROM cust_calls x WHERE 1 < (SELECT COUNT (*) FROM cust_calls y WHERE x.customer_num = y.customer_num)
3-16
Self-Joins
Query 3-14 locates the same two duplicate customer_num values as Query 3-13 and returns the rows shown in Query Result 3-14:
Query Result 3-14
customer_num call_dtime 116 1993-11-28 13:34 116 1993-12-21 11:24
You can use the rowid, shown earlier in a self-join, to locate the internal record number associated with a row in a database table. The rowid is, in effect, a hidden column in every table. The sequential values of rowid have no special signicance and may vary depending on the location of the physical data in the chunk. Your rowid may vary from the example shown. The use of rowid is discussed in detail in the INFORMIX-OnLine Dynamic Server Administrators Guide. Query 3-15 uses the rowid and the wildcard asterisk symbol (*) in the SELECT clause to retrieve every row in the manufact table and their corresponding rowids:
Query 3-15
SELECT rowid, * FROM manufact
Query Result 3-15

rowid manu_code manu_name 257 258 259 260 261 262 263 264 265 SMT ANZ NRG HSK HRO SHM KAR NKL PRC Smith Anza Norge Husky Hero Shimara Karsten Nikolus ProCycle lead_time 3 5 7 5 4 30 21 8 9
Self-Joins
You also can use the rowid when you select a specic column, as shown in Query 3-16:
Query 3-16
SELECT rowid, manu_code FROM manufact
Query Result 3-16

rowid manu_code 258 261 260 263 264 259 265 262 257 ANZ HRO HSK KAR NKL NRG PRC SHM SMT
You can use the rowid in the WHERE clause to retrieve rows based on their internal record number. This method is handy when no other unique column exists in a table. Query 3-17 uses a rowid from Query 3-16:
Query 3-17
SELECT * FROM manufact WHERE rowid = 263
Query 3-17 returns the row shown in Query Result 3-17:

Query Result 3-17
manu_code manu_name KAR Karsten lead_time 21
3-18
Self-Joins Using the USER Function

To obtain additional information about a table, you can combine the rowid with the USER function. Query 3-18 assigns the label username to the USER expression column and returns this information about the cust_calls table:
Query 3-18
SELECT USER username, rowid FROM cust_calls
Query Result 3-18

username zenda zenda zenda zenda zenda zenda zenda rowid 257 258 259 513 514 515 769
You also can use the USER function in a WHERE clause when you select the rowid. Query 3-19 returns the rowid for only those rows inserted or updated by the user who performs the query:
Query 3-19
SELECT rowid FROM cust_calls WHERE user_id = USER
For example, if the user richc used Query 3-19, the output would be as shown in Query Result 3-19:
Query Result 3-19
rowid 258 259
Self-Joins Using the DBSERVERNAME Function

With INFORMIX-OnLine Dynamic Server, you can add the DBSERVERNAME keyword (or its synonym, SITENAME) to a query to nd out where the current database resides. Query 3-20 nds the database server name and the user name as well as the rowid and the tabid, which is the serial interval table identier for system catalog tables:
Query 3-20
SELECT DBSERVERNAME server, tabid, rowid, USER username FROM systables WHERE tabid >= 105 OR rowid <= 260 ORDER BY rowid
Query 3-20 assigns display labels to the DBSERVERNAME and USER expressions and returns the 10 rows from the systables system catalog table, as shown in Query Result 3-20:
Query Result 3-20
server manatee manatee manatee manatee manatee manatee manatee manatee manatee manatee tabid 1 2 3 4 105 106 107 108 109 110 rowid username 257 258 259 260 274 1025 1026 1027 1028 1029 zenda zenda zenda zenda zenda zenda zenda zenda zenda zenda
Note that you should never store a rowid in a permanent table or attempt to use it as a foreign key because the rowid can change. For example, if a table is dropped and then reloaded from external data, all the rowids are different.
USER and DBSERVERNAME were discussed in Chapter 2, Composing
Simple SELECT Statements.
3-20
Outer Joins
Outer Joins
Chapter 2, Composing Simple SELECT Statements, showed how to create and use some simple joins. Whereas a simple join treats two or more joined tables equally, an outer join treats two or more joined tables unsymmetrically. It makes one of the tables dominant (also called preserved) over the other subservient tables. Outer joins occur in four basic types:
s s s s
A simple outer join on two tables A simple outer join to a third table An outer join for a simple join to a third table An outer join for an outer join to a third table
This section discusses these types of outer joins. See the discussion of outer joins in Chapter 1 of the Informix Guide to SQL: Syntax for full information on their syntax, use, and logic. In a simple join, the result contains only the combinations of rows from the tables that satisfy the join conditions. Rows that do not satisfy the join conditions are discarded. In an outer join, the result contains the combinations of rows from the tables that satisfy the join conditions. Rows from the dominant table that would otherwise be discarded are preserved, even though no matching row was found in the subservient table. The dominant-table rows that do not have a matching subservient-table row receive a row of nulls before the selected columns are projected. An outer join applies conditions to the subservient table while sequentially applying the join conditions to the rows of the dominant table. The conditions are expressed in a WHERE clause. An outer join must have a SELECT clause, a FROM clause, and a WHERE clause. You transform a simple join into an outer join by inserting the keyword OUTER directly before the name of the subservient tables in the FROM clause. As shown later in this section, you can include the OUTER keyword more than once in your query.
Outer Joins
Before you use outer joins heavily, you should determine whether one or more simple joins can work. You often can get by with a simple join when you do not need supplemental information from other tables. The examples in this section use table aliases for brevity. Table aliases are discussed in Chapter 2, Composing Simple SELECT Statements.
Simple Join
Query 3-21 is an example of the type of simple join on the customer and cust_calls tables that is shown in Chapter 2, Composing Simple SELECT Statements.
Query 3-21
SELECT c.customer_num, c.lname, c.company, c.phone, u.call_dtime, u.call_descr FROM customer c, cust_calls u WHERE c.customer_num = u.customer_num
Query 3-21 returns only those rows where the customer has made a call to customer service, as shown in Query Result 3-21:
3-22
Outer Joins
Query Result 3-21

customer_num lname company phone call_dtime call_descr 106 Watson Watson & Son 415-389-8789 1994-06-12 08:20 Order was received, but two of the cans of ANZ tennis balls within the case were empty 110 Jaeger AA Athletics 415-743-3611 1994-07-07 10:24 Order placed one month ago (6/7) not received. 119 Shorter The Triathletes Club 609-663-6079 1994-07-01 15:00 Bill does not reflect credit from previous order 121 Wallack City Sports 302-366-7511 1994-07-10 14:05 Customer likes our merchandise. Requests that we stock more types of infant joggers. Will call back to place order. 127 Satifer Big Blue Bike Shop 312-944-5691 1994-07-31 14:30 Received Hero watches (item # 304) instead of ANZ watches 116 Parmelee Olympic City 415-534-8822 1993-11-28 13:34 Received plain white swim caps (313 ANZ) instead of navy with team logo (313 SHM) 116 Parmelee Olympic City 415-534-8822 1993-12-21 11:24 Second complaint from this customer! Received two cases right-handed outfielder gloves (1 HRO) instead of one case lefties.
customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr
customer_num lname company phone call_dtime call_descr
Outer Joins Simple Outer Join on Two Tables

Query 3-22 uses the same select list, tables, and comparison condition as the preceding example, but this time it creates a simple outer join:
Query 3-22
SELECT c.customer_num, c.lname, c.company, c.phone, u.call_dtime, u.call_descr FROM customer c, OUTER cust_calls u WHERE c.customer_num = u.customer_num
The addition of the keyword OUTER in front of the cust_calls table makes it the subservient table. An outer join causes the query to return information on all customers, whether or not they have made calls to customer service. All rows from the dominant customer table are retrieved, and null values are assigned to corresponding rows from the subservient cust_calls table, as shown in Query Result 3-22:
3-24
Outer Joins
customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr
101 Pauli All Sports Supplies 408-789-8075
Query Result 3-22
102 Sadler Sports Spot 415-822-1289
103 Currie Phils Sports 415-328-4543
104 Higgins Play Ball! 415-368-1100
105 Vector Los Altos Sports 415-776-3249
106 Watson Watson & Son 415-389-8789 1994-06-12 08:20 Order was received, but two of the cans of ANZ tennis balls within the case were empty 107 Ream Athletic Supplies 415-356-9876
customer_num lname company phone call_dtime call_descr customer_num lname company phone call_dtime call_descr . .
108 Quinn Quinns Sports 415-544-8729
Outer Joins Outer Join for a Simple Join to a Third Table

Query 3-23 shows an outer join that is the result of a simple join to a third table. This second type of outer join is known as a nested simple join.
Query 3-23
SELECT c.customer_num, c.lname, o.order_num, i.stock_num, i.manu_code, i.quantity FROM customer c, OUTER (orders o, items i) WHERE c.customer_num = o.customer_num AND o.order_num = i.order_num AND manu_code IN ('KAR', 'SHM') ORDER BY lname
Query 3-23 rst performs a simple join on the orders and items tables, retrieving information on all orders for items with a manu_code of KAR or SHM. It then performs an outer join to combine this information with data from the dominant customer table. An optional ORDER BY clause reorganizes the data into the form shown in Query Result 3-23:
3-26
Outer Joins
Query Result 3-23

customer_num lname 114 118 113 103 115 123 123 125 104 110 120 120 111 112 128 109 126 122 116 101 124 108 107 102 127 127 127 119 117 105 121 106 Albertson Baxter Beatty Currie Grant Hanlon Hanlon Henry Higgins Jaeger Jewell Jewell Keyes Lawson Lessor Miller Neelie OBrian Parmelee Pauli Putnum Quinn Ream Sadler Satifer Satifer Satifer Shorter Sipes Vector Wallack Watson order_num stock_num manu_code quantity
1020 1020
301 KAR 204 KAR
4 2
1017 1017
202 KAR 301 SHM
1 2
1019
111 SHM
1021
202 KAR
1023 1023 1023 1016
306 105 110 101
SHM SHM SHM SHM
1 1 1 2
1018
302 KAR
Outer Join for an Outer Join to a Third Table

Query 3-24 creates an outer join that is the result of an outer join to a third table. This third type is known as a nested outer join.
Query 3-24
SELECT c.customer_num, lname, o.order_num, stock_num, manu_code, quantity FROM customer c, OUTER (orders o, OUTER items i) WHERE c.customer_num = o.customer_num AND o.order_num = i.order_num AND manu_code IN ('KAR', 'SHM') ORDER BY lname
Outer Joins
Query 3-24 rst performs an outer join on the orders and items tables, retrieving information on all orders for items with a manu_code of KAR or SHM. It then performs an outer join, which combines this information with data from the dominant customer table. Query 3-24 preserves order numbers that the previous example eliminated, returning rows for orders that do not contain items with either manufacturer code. An optional ORDER BY clause reorganizes the data, as shown in Query Result 3-24:
Query Result 3-24
customer_num lname 114 118 113 103 115 123 123 125 104 104 104 104 110 110 120 120 111 112 128 109 126 122 116 101 124 108 107 102 127 127 127 119 117 117 105 121 106 106 Albertson Baxter Beatty Currie Grant Hanlon Hanlon Henry Higgins Higgins Higgins Higgins Jaeger Jaeger Jewell Jewell Keyes Lawson Lessor Miller Neelie OBrian Parmelee Pauli Putnum Quinn Ream Sadler Satifer Satifer Satifer Shorter Sipes Sipes Vector Wallack Watson Watson order_num stock_num manu_code quantity
1010 1020 1020 1011 1001 1013 1003 1008 1015 1017 1017 1009 1006
204 KAR 301 KAR
2 4
301 SHM 202 KAR
2 1
1022 1019 1005 1002 1021
111 SHM
202 KAR
1023 1023 1023 1016 1012 1007 1018 1014 1004
110 105 306 101
SHM SHM SHM SHM
1 1 1 2
302 KAR
3-28
Outer Joins
You can state the join conditions in two ways when you apply an outer join to the result of an outer join to a third table. The two subservient tables are joined, but you can join the dominant table to either subservient table without affecting the results if the dominant table and the subservient table share a common column.
Outer Join of Two Tables to a Third Table

Query 3-25 shows an outer join that is the result of an outer join of each of two tables to a third table. In this fourth type of outer join, join relationships are possible only between the dominant table and the subservient tables.
Query 3-25
SELECT c.customer_num, lname, o.order_num, order_date, call_dtime FROM customer c, OUTER orders o, OUTER cust_calls x WHERE c.customer_num = o.customer_num AND c.customer_num = x.customer_num ORDER BY lname INTO TEMP service
Query 3-25 individually joins the subservient tables orders and cust_calls to the dominant customer table; it does not join the two subservient tables. An INTO TEMP clause selects the results into a temporary table for further manipulation or queries, as shown in Query Result 3-25.
Outer Joins
Query Result 3-25

customer_num lname 114 118 113 103 115 123 125 104 104 104 104 110 110 120 111 112 109 128 126 122 116 116 101 124 108 107 102 127 119 117 117 105 121 106 106 Albertson Baxter Beatty Currie Grant Hanlon Henry Higgins Higgins Higgins Higgins Jaeger Jaeger Jewell Keyes Lawson Miller Moore Neelie OBrian Parmelee Parmelee Pauli Putnum Quinn Ream Sadler Satifer Shorter Sipes Sipes Vector Wallack Watson Watson order_num order_date call_dtime
1010 06/17/1994 1020 07/11/1994 1003 1001 1013 1011 1015 1008 1017 1009 1006 05/22/1994 05/20/1994 06/22/1994 06/18/1994 06/27/1994 1994-07-07 10:24 06/07/1994 1994-07-07 10:24 07/09/1994 06/14/1994 05/30/1994
1022 1019 1005 1005 1002 1021
07/24/1994 07/11/1994 05/24/1994 1993-12-21 11:24 05/24/1994 1993-11-28 13:34 05/21/1994 07/23/1994
1023 1016 1007 1012
07/24/1994 1994-07-31 14:30 06/29/1994 1994-07-01 15:00 05/31/1994 06/18/1994
1018 07/10/1994 1994-07-10 14:05 1004 05/22/1994 1994-06-12 08:20 1014 06/25/1994 1994-06-12 08:20
Note that if Query 3-25 had tried to create a join condition between the two subservient tables o and x, as shown in Query 3-26, an error message would have indicated the creation of a two-sided outer join:
Query 3-26
WHERE o.customer_num = x.customer_num
3-30
Subqueries in SELECT Statements

A SELECT statement nested in the WHERE clause of another SELECT statement (or in an INSERT, DELETE, or UPDATE statement) is called a subquery. Each subquery must contain a SELECT clause and a FROM clause, and it must be enclosed in parentheses, which tells the database server to perform that operation rst. Subqueries can be correlated or uncorrelated. A subquery (or inner SELECT statement) is correlated when the value it produces depends on a value produced by the outer SELECT statement that contains it. Any other kind of subquery is considered uncorrelated. The important feature of a correlated subquery is that, because it depends on a value from the outer SELECT, it must be executed repeatedly, once for every value produced by the outer SELECT. An uncorrelated subquery is executed only once. You can construct a SELECT statement with a subquery to replace two separate SELECT statements. Subqueries in SELECT statements allow you to perform the following actions:
s s
Compare an expression to the result of another SELECT statement Determine whether an expression is included in the results of another SELECT statement Determine whether any rows are selected by another SELECT statement
An optional WHERE clause in a subquery often is used to narrow the search condition.
A subquery selects and returns values to the rst or outer SELECT statement. A subquery can return no value, a single value, or a set of values.
s
If it returns no value, the query does not return any rows. Such a subquery is equivalent to a null value. If it returns one value, the subquery returns either one aggregate expression or else selects exactly one row and one column. Such a subquery is equivalent to a single number or character value. If it returns a list or set of values, the subquery returns either one row or one column.
The following keywords introduce a subquery in the WHERE clause of a SELECT statement:
s s s s
ALL ANY IN EXISTS
You can use any relational operator with ALL and ANY to compare something to every one of (ALL), or to any one of (ANY), the values that the subquery produces. You can use the keyword SOME in place of ANY. The operator IN is equivalent to =ANY. To create the opposite search condition, use the keyword NOT or a different relational operator. The EXISTS operator tests a subquery to see if it found any values; that is, it asks if the result of the subquery is not null. See Chapter 1 in the Informix Guide to SQL: Syntax for the complete syntax used in creating a condition with a subquery.
3-32
Using ALL
Using ALL
Use the keyword ALL preceding a subquery to determine whether a comparison is true for every value returned. If the subquery returns no values, the search condition is true. (If it returns no values, the condition is true of all the zero values.) Query 3-27 lists the following information for all orders that contain an item for which the total price is less than the total price on every item in order number 1023:
Query 3-27
SELECT order_num, stock_num, manu_code, total_price FROM items WHERE total_price < ALL (SELECT total_price FROM items WHERE order_num = 1023)
Query Result 3-27

order_num stock_num manu_code total_price 1003 1005 1006 1010 1013 1013 1018 9 6 6 6 5 6 302 ANZ SMT SMT SMT ANZ SMT KAR $20.00 $36.00 $36.00 $36.00 $19.80 $36.00 $15.00
Using ANY
Using ANY
Use the keyword ANY (or its synonym SOME) preceding a subquery to determine whether a comparison is true for at least one of the values returned. If the subquery returns no values, the search condition is false. (Because there were no values, the condition cannot be true for one of them.) Query 3-28 nds the order number of all orders that contain an item for which the total price is greater than the total price of any one of the items in order number 1005.
Query 3-28
SELECT DISTINCT order_num FROM items WHERE total_price > ANY (SELECT total_price FROM items WHERE order_num = 1005)
Query Result 3-28

order_num 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023
3-34
Single-Valued Subqueries
Single-Valued Subqueries
You do not need to include the keyword ALL or ANY if you know the subquery can return exactly one value to the outer-level query. A subquery that returns exactly one value can be treated like a function. This kind of subquery often uses an aggregate function because aggregate functions always return single values Query 3-29 uses the aggregate function MAX in a subquery to nd the order_num for orders that include the maximum number of volleyball nets.
Query 3-29
SELECT order_num FROM items WHERE stock_num = 9 AND quantity = (SELECT MAX (quantity) FROM items WHERE stock_num = 9)
Query Result 3-29

order_num 1012
Query 3-30 uses the aggregate function MIN in the subquery to select items for which the total price is higher than 10 times the minimum price:
Query 3-30
SELECT order_num, stock_num, manu_code, total_price FROM items x WHERE total_price > (SELECT 10 * MIN (total_price) FROM items WHERE order_num = x.order_num)
Query Result 3-30

order_num stock_num manu_code 1003 1018 1018 1018 8 307 110 304 ANZ PRC PRC HRO total_price $840.00 $500.00 $236.00 $280.00
Correlated Subqueries
Correlated Subqueries
Query 3-31 is an example of a correlated subquery, which returns a list of the 10 earliest shipping dates in the orders table. It includes an ORDER BY clause after the subquery to order the results because you cannot include ORDER BY within a subquery.
Query 3-31
SELECT po_num, ship_date FROM orders main WHERE 10 > (SELECT COUNT (DISTINCT ship_date) FROM orders sub WHERE sub.ship_date > main.ship_date) AND ship_date IS NOT NULL ORDER BY ship_date, po_num
The subquery is correlated because the number it produces depends on main.ship_date, a value produced by the outer SELECT. Thus, the subquery must be executed anew for every row that the outer query considers. Query 3-31 uses the COUNT function to return a value to the main query. The ORDER BY clause then orders the data. The query locates and returns the 13 rows that have the 10 latest shipping dates, as shown in Query Result 3-31:
Query Result 3-31
po_num 4745 278701 429Q 8052 B77897 LZ230 B77930 PC6782 DM354331 S22942 MA003 W2286 Z55709 C3288 KF2961 W9925 ship_date 06/21/1994 06/29/1994 06/29/1994 07/03/1994 07/03/1994 07/06/1994 07/10/1994 07/12/1994 07/13/1994 07/13/1994 07/16/1994 07/16/1994 07/16/1994 07/25/1994 07/30/1994 07/30/1994
3-36
Using EXISTS
If you use a correlated subquery, such as Query 3-31, on a very large table, you should index the ship_date column to improve performance. Otherwise, this SELECT statement might be considered somewhat inefcient because it executes the subquery once for every row of the table. Indexing and performance issues are discussed in the administrators guide for your database server.
Using EXISTS
The keyword EXISTS is known as an existential qualier because the subquery is true only if the outer SELECT, shown in Query 3-32a, nds at least one row:
Query 3-32a
SELECT UNIQUE manu_name, lead_time FROM manufact WHERE EXISTS (SELECT * FROM stock WHERE description MATCHES '*shoe*' AND manufact.manu_code = stock.manu_code)
You often can construct a query with EXISTS that is equivalent to one that uses IN. You also can substitute =ANY for IN, as shown in Query 3-32b:
Query 3-32b
SELECT UNIQUE manu_name, lead_time FROM stock, manufact WHERE manufact.manu_code IN (SELECT manu_code FROM stock WHERE description MATCHES '*shoe*') AND stock.manu_code = manufact.manu_code
Query 3-32a and Query 3-32b return rows for the manufacturers that produce a kind of shoe as well as the lead time for ordering the product. These results are shown in Query Result 3-32:
Query Result 3-32
manu_name Anza Hero Karsten Nikolus ProCycle Shimara lead_time 5 4 21 8 9 30
Using EXISTS
Note that you cannot use the predicate IN for a subquery that contains a column with a TEXT or BYTE data type. Add the keyword NOT to IN or to EXISTS to create a search condition that is the opposite of the one in the preceding queries. You also can substitute !=ALL for NOT IN. Query 3-33 shows two ways to do the same thing. One way might allow the database server to do less work than the other, depending on the design of the database and the size of the tables. To nd out which query might be better, you can use the SET EXPLAIN command to get a listing of the query plan. SET EXPLAIN is discussed in the INFORMIX-OnLine Dynamic Server Performance Guide and in Chapter 1 of the Informix Guide to SQL: Syntax.
Query 3-33
SELECT customer_num, company FROM customer WHERE customer_num NOT IN (SELECT customer_num FROM orders WHERE customer.customer_num = orders.customer_num) SELECT customer_num, company FROM customer WHERE NOT EXISTS (SELECT * FROM orders WHERE customer.customer_num = orders.customer_num)
Each statement in Query 3-33 returns the rows shown in Query Result 3-33, which identify customers who have not placed orders:
Query Result 3-33
customer_num company 102 103 105 107 108 109 113 114 118 125 128 Sports Spot Phils Sports Los Altos Sports Athletic Supplies Quinns Sports Sport Stuff Sportstown Sporting Place Blue Ribbon Sports Total Fitness Sports Phoenix University
3-38
Using EXISTS
Note that the keywords EXISTS and IN are used for the set operation known as intersection, and the keywords NOT EXISTS and NOT IN are used for the set operation known as difference. These concepts are discussed in Set Operations on page 3-41. Query 3-34 identies all the items in the stock table that have not been ordered yet by performing a subquery on the items table:
Query 3-34
SELECT stock.* FROM stock WHERE NOT EXISTS (SELECT * FROM items WHERE stock.stock_num = items.stock_num AND stock.manu_code = items.manu_code)
Using EXISTS
It returns the rows shown in Query Result 3-34:

stock_num manu_code description unit_price unit unit_descr
Query Result 3-34
101 102 102 105 106 107 108 109 110 110 112 113 201 202 203 205 205 301 301 301 301 302 303 305 306 308 309 310 310 311 312 312 313 313
PRC SHM PRC PRC PRC PRC SHM SHM ANZ HRO SHM SHM KAR NKL NKL NKL HRO NKL HRO PRC ANZ HRO KAR HRO PRC PRC SHM SHM ANZ SHM SHM HRO SHM ANZ
bicycle tires bicycle brakes bicycle brakes bicycle wheels bicycle stem bicycle saddle crankset pedal binding helmet helmet 12-spd, assmbld 18-spd, assmbld golf shoes metal woods irons/wedge 3 golf balls 3 golf balls running shoes running shoes running shoes running shoes ice pack socks first-aid kit tandem adapter twin jogger ear drops kick board kick board water gloves racer goggles racer goggles swim cap swim cap
$88.00 $220.00 $480.00 $53.00 $23.00 $70.00 $45.00 $200.00 $244.00 $260.00 $549.00 $685.90 $90.00 $174.00 $670.00 $312.00 $312.00 $97.00 $42.50 $75.00 $95.00 $4.50 $36.00 $48.00 $160.00 $280.00 $40.00 $80.00 $84.00 $48.00 $96.00 $72.00 $72.00 $60.00
box case case pair each pair each case case case each each each case case case case each each each each each box case each each case case case box box box box box
4/box 4 sets/case 4 sets/case pair each pair each 4 pairs/case 4/case 4/case each each each 2 sets/case 2 sets/case 24/case 24/case each each each each each 24 pairs/box 4/case each each 20/case 10/case 12/case 4 pairs/box 12/box 12/box 12/box 12/box
Note that no logical limit exists to the number of subqueries a SELECT statement can have, but the size of any statement is physically limited when considered as a character string. However, this limit is probably larger than any practical statement you are likely to compose.
3-40
Set Operations
Perhaps you want to check whether information has been entered correctly in the databaes. One way to nd errors in a database is to write a query that returns output only when errors exist. A subquery of this type serves as a kind of audit query, as shown in Query 3-35:
Query 3-35
SELECT * FROM items WHERE total_price != quantity * (SELECT unit_price FROM stock WHERE stock.stock_num = items.stock_num AND stock.manu_code = items.manu_code)
Query 3-35 returns only those rows for which the total price of an item on an order is not equal to the stock unit price times the order quantity. Assuming that no discount has been applied, such rows must have been entered incorrectly in the database. The query returns rows only when errors occur. If information is correctly inserted into the database, no rows are returned.
Query Result 3-35
item_num order_num stock_num manu_code quantity total_price
1 2
1004 1006
1 HRO 5 NRG
1 5
$960.00 $190.00
Set Operations
The standard set operations union, intersection, and difference let you manipulate database information. These three operations enable you to use SELECT statements to check the integrity of your database after you perform an update, insert, or delete. They can be useful when you transfer data to a history table, for example, and want to verify that the correct data is in the history table before you delete it from the original table.
Union
Union
The union operation uses the UNION keyword, or operator, to combine two queries into a single compound query. You can use the UNION keyword between two or more SELECT statements to unite them and produce a temporary table containing rows that exist in any or all of the original tables. (Note that you cannot use a UNION operator inside a subquery or in the denition of a view.) Figure 3-1 illustrates the union set operation.
Figure 3-1 The union set operation
SELECT DISTINCT stock_num, manu_code FROM stock WHERE unit_price < 25.00 UNION SELECT stock_num, manu_code FROM items WHERE quantity > 3
quantity greater than 3 less than or equal to 3 qualifies quantity > 3 qualifies unit_price < 25.00
less than 25.00 unit_price greater than or equal to 25.00
qualifies
The UNION keyword selects all rows from the two queries, removes duplicates, and returns what is left. Because the results of the queries are combined into a single result, the select list in each query must have the same number of columns. Also, the corresponding columns selected from each table must be of the same data type (CHARACTER type columns must be the same length), and these corresponding columns must either all allow or all disallow nulls.
3-42
Union
Query 3-36 performs a union on the stock_num and manu_code columns in the stock and items tables:
Query 3-36
SELECT DISTINCT stock_num, manu_code FROM stock WHERE unit_price < 25.00 UNION SELECT stock_num, manu_code FROM items WHERE quantity > 3
Query 3-36 selects those items that have a unit price of less than $25.00 or that have been ordered in quantities greater than three and lists their stock_num and manu_code, as shown in Query Result 3-36:
Query Result 3-36
stock_num manu_code 5 5 5 9 103 106 201 301 302 302 ANZ NRG SMT ANZ PRC PRC NKL KAR HRO KAR
If you include an ORDER BY clause, it must follow Query 3-36 and use an integer, not an identier, to refer to the ordering column. Ordering takes place after the set operation is complete.
Union
Query 3-37
SELECT DISTINCT stock_num, manu_code FROM stock WHERE unit_price < 25.00 UNION SELECT stock_num, manu_code FROM items WHERE quantity > 3 ORDER BY 2
The compound query in Query 3-37 selects the same rows as Query 3-36 but displays them in order of the manufacturer code, as shown in Query Result 3-37:
Query Result 3-37
stock_num manu_code 5 9 302 301 302 201 5 103 106 5 ANZ ANZ HRO KAR KAR NKL NRG PRC PRC SMT
By default, the UNION keyword excludes duplicate rows. Add the optional keyword ALL, as shown in Query 3-38, to retain the duplicate values:
Query 3-38
SELECT stock_num, manu_code FROM stock WHERE unit_price < 25.00 UNION ALL SELECT stock_num, manu_code FROM items WHERE quantity > 3 ORDER BY 2 INTO TEMP stockitem
3-44
Union
Query 3-38 uses the UNION ALL keywords to unite two SELECT statements and puts the results into a temporary table by adding an INTO TEMP clause after the nal SELECT. It returns the same rows as Query 3-37 but also includes duplicate values.
Query Result 3-38
stock_num manu_code 9 5 9 5 9 5 5 5 302 302 301 201 5 5 103 106 5 5 ANZ ANZ ANZ ANZ ANZ ANZ ANZ ANZ HRO KAR KAR NKL NRG NRG PRC PRC SMT SMT
Corresponding columns in the select lists for the combined queries must have identical data types, but the columns do not need to use the same identier. Query 3-39 selects the state column from the customer table and the corresponding code column from the state table:
Query 3-39
SELECT DISTINCT state FROM customer WHERE customer_num BETWEEN 120 AND 125 UNION SELECT DISTINCT code FROM state WHERE sname MATCHES '*a'
Union
Query Result 3-39 returns state code abbreviations for customer numbers 120 through 125, or for states whose sname ends in A or a:
Query Result 3-39
state AK AL AZ CA DE FL GA IA IN LA MA MN MT NC ND NE NJ NV OK PA SC SD VA WV
In compound queries, the column names or display labels in the rst SELECT statement are the ones that appear in the results. Thus, in Query 3-40, the column name state from the rst SELECT statement is used instead of the column name code from the second. Query 3-40 performs a union on three tables. The maximum number of unions depends on the practicality of the application and any memory limitations.
3-46
Union
Query 3-40
SELECT stock_num, manu_code FROM stock WHERE unit_price > 600.00 UNION ALL SELECT stock_num, manu_code FROM catalog WHERE catalog_num = 10025 UNION ALL SELECT stock_num, manu_code FROM items WHERE quantity = 10 ORDER BY 2
Query 3-40 selects items where the unit_price in the stock table is greater than $600, the catalog_num in the catalog table is 10025, or the quantity in the items table is 10; and the query orders the data by manu_code. The results are shown in Query Result 3-40:
Query Result 3-40
stock_num manu_code 5 9 8 4 1 203 5 106 113 ANZ ANZ ANZ HSK HSK NKL NRG PRC SHM
See Chapter 1 of the Informix Guide to SQL: Syntax for the complete syntax of the SELECT statement and the UNION operator. See also Chapter 5, Programming with SQL,and Chapter 6, Modifying Data Through SQL Programs,as well as the product manuals for information specic to the INFORMIX-4GL and INFORMIX-ESQL/C products and any limitations involving the INTO clause and compound queries. Query 3-41 uses a combined query to select data into a temporary table and then adds a simple query to order and display it. You must separate the combined and simple queries with a semicolon.
Union
The combined query uses a literal in the select list to tag the output of part of a union so it can be distinguished later. The tag is given the label sortkey. The simple query uses that tag as a sort key for ordering the retrieved rows.
Query 3-41
SELECT '1' sortkey, lname, fname, company, city, state, phone FROM customer x WHERE state = 'CA' UNION SELECT '2' sortkey, lname, fname, company, city, state, phone FROM customer y WHERE state <> 'CA' INTO TEMP calcust; SELECT * FROM calcust ORDER BY 1
Query 3-41 creates a list where the California customers, the ones called most frequently, appear rst, as shown in Query Result 3-41:
3-48
Union
Query Result 3-41

sortkey lname fname company city state phone sortkey lname fname company city state phone sortkey lname fname company city state phone sortkey lname fname company city state phone . . . sortkey lname fname company city state phone sortkey lname fname company city state phone sortkey lname fname company city state phone 1 Baxter Dick Blue Ribbon Sports Oakland CA 415-655-0011 1 Beatty Lana Sportstown Menlo Park CA 415-356-9982 1 Currie Philip Phils Sports Palo Alto CA 415-328-4543 1 Grant Alfred Gold Medal Sports Menlo Park CA 415-356-1123
2 Satifer Kim Big Blue Bike Shop Blue Island NY 312-944-5691 2 Shorter Bob The Triathletes Club Cherry Hill NJ 609-663-6079 2 Wallack Jason City Sports Wilmington DE 302-366-7511
Intersection
Intersection
The intersection of two sets of rows produces a table containing rows that exist in both the original tables. Use the keyword EXISTS or IN to introduce subqueries that show the intersection of two sets. Figure 3-2 illustrates the intersection set operation.
Figure 3-2 The intersection set operation
SELECT stock_num, manu_code, unit_price FROM stock WHERE stock_num IN (SELECT stock_num FROM items) ORDER BY stock_num
stock_num exists in items table not in items table stock table
exists in stock table stock_num not in stock table
qualifies items table
Query 3-42 is an example of a nested SELECT statement that shows the intersection of the stock and items tables:
Query 3-42
SELECT stock_num, manu_code, unit_price FROM stock WHERE stock_num IN (SELECT stock_num FROM items) ORDER BY stock_num
Query Result 3-42 contains all the elements from both sets, returning the following 57 rows:
3-50
Intersection
Query Result 3-42

stock_num manu_code unit_price 1 1 1 2 3 3 4 4 5 5 5 6 6 7 8 9 101 101 103 104 105 105 109 109 110 110 110 110 110 111 114 201 201 201 202 202 204 205 205 205 301 301 301 301 301 301 302 302 303 303 304 304 306 306 307 309 HRO HSK SMT HRO HSK SHM HRO HSK ANZ NRG SMT ANZ SMT HRO ANZ ANZ PRC SHM PRC PRC PRC SHM PRC SHM ANZ HRO HSK PRC SHM SHM PRC ANZ KAR NKL KAR NKL KAR ANZ HRO NKL ANZ HRO KAR NKL PRC SHM HRO KAR KAR PRC ANZ HRO PRC SHM PRC HRO $250.00z $800.00 $450.00 $126.00 $240.00 $280.00 $480.00 $960.00 $19.80 $28.00 $25.00 $48.00 $36.00 $600.00 $840.00 $20.00 $88.00 $68.00 $20.00 $58.00 $53.00 $80.00 $30.00 $200.00 $244.00 $260.00 $308.00 $236.00 $228.00 $499.99 $120.00 $75.00 $90.00 $37.50 $230.00 $174.00 $45.00 $312.00 $312.00 $312.00 $95.00 $42.50 $87.00 $97.00 $75.00 $102.00 $4.50 $5.00 $36.00 $48.00 $170.00 $280.00 $160.00 $190.00 $250.00 $40.00
Difference
Difference
The difference between two sets of rows produces a table containing rows in the rst set that are not also in the second set. Use the keywords NOT EXISTS or NOT IN to introduce subqueries that show the difference between two sets. Figure 3-3 illustrates the difference set operation.
Figure 3-3 The difference set operation
SELECT stock_num, manu_code, unit_price FROM stock WHERE stock_num NOT IN (SELECT stock_num FROM items) ORDER BY stock_num
stock_num exists in items table not in items table stock table
stock_num
exists in stock table not in stock table
qualifies items table
3-52
Query 3-43 is an example of a nested SELECT statement that shows the difference between the stock and items tables:
Query 3-43
SELECT stock_num, manu_code, unit_price FROM stock WHERE stock_num NOT IN (SELECT stock_num FROM items) ORDER BY stock_num
Query Result 3-43 contains all the elements from only the rst set, returning 17 rows:
Query Result 3-43
stock_num manu_code unit_price 102 102 106 107 108 112 113 203 305 308 310 310 311 312 312 313 313 PRC SHM PRC PRC SHM SHM SHM NKL HRO PRC ANZ SHM SHM HRO SHM ANZ SHM $480.00 $220.00 $23.00 $70.00 $45.00 $549.00 $685.90 $670.00 $48.00 $280.00 $84.00 $80.00 $48.00 $72.00 $96.00 $60.00 $72.00
Summary
Summary
This chapter was built on concepts introduced in Chapter 2, Composing Simple SELECT Statements. It provided sample syntax and results for more advanced kinds of SELECT statements, which are used to perform a query on a relational database. This chapter has presented the following material.
s
Introduced the GROUP BY and HAVING clauses, which can be used with aggregates to return groups of rows and apply conditions to those groups Described how to use the rowid to retrieve internal record numbers from tables and system catalog tables and discussed the serial iternal table identier or tabid Showed how to join a table to itself with a self-join to compare values in a column with other values in the same column and to identify duplicates Introduced the keyword OUTER, explained how an outer join treats two or more tables asymmetrically, and provided examples of the four kinds of outer join Described how to create correlated and uncorrelated subqueries by nesting a SELECT statement in the WHERE clause of another SELECT statement and showed the use of aggregate functions in subqueries Demonstrated the use of the keywords ALL, ANY, EXISTS, IN, and SOME in creating subqueries, and the effect of adding the keyword NOT or a relational operator Discussed the set operations union, intersection, and difference Showed how to use the UNION and UNION ALL keywords to create compound queries consisting of two or more SELECT statements
s s
3-54
Chapter
Modifying Data
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4-4 4-4 4-5 4-5 4-6 4-7 4-7 4-10 4-11 4-12 4-13 4-14 4-15 4-15 4-16 4-18 4-19 4-19 4-20 4-21 4-23 4-25 4-26 4-26 4-27 4-27
Statements That Modify Data . . . . . . . Deleting Rows . . . . . . . . . . . Deleting All Rows of a Table . . . . . Deleting a Known Number of Rows . . . Deleting an Unknown Number of Rows . Complicated Delete Conditions . . . . Inserting Rows . . . . . . . . . . . Single Rows . . . . . . . . . . Multiple Rows and Expressions . . . . Restrictions on the Insert-Selection. . . Updating Rows . . . . . . . . . . . Selecting Rows to Update . . . . . . Updating with Uniform Values . . . . Impossible Updates . . . . . . . . Updating with Selected Values . . . . Database Privileges. . . . . Displaying Table Privileges . . . . . . . . . . . .
Data Integrity. . . . . . . . . . . . . Entity Integrity . . . . . . . . . . . Semantic Integrity . . . . . . . . . . Referential Integrity . . . . . . . . . Using the ON DELETE CASCADE Option
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupted Modications . . . . . . . . . . . . . . . . The Transaction. . . . . . . . . . . . . . . . . . . Transaction Logging . . . . . . . . . . . . . . . . . Logging and Cascading Deletes . . . . . . . . . . . . Specifying Transactions . . . . . . . . . . . . . . . .
Archives and Logs . . . . . . . . . . . . . . . . . . . Archiving with INFORMIX-SE . . . . . . . . . . . . . Archiving with INFORMIX-OnLine Dynamic Server . . . . . . Concurrency and Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-28 4-28 4-29 4-30 4-31 4-32 4-32
Data Replication . . . . . . . . . . . . . . . . INFORMIX-OnLine Dynamic Server Data Replication . Summary . . . . . . . . . . . . . . . . . .
4-2
M
s s s
odifying data is fundamentally different from querying data. Querying data involves examining the contents of tables. Modifying data involves changing the contents of tables. Think about what happens if the system hardware or software fails during a query. In this case, the effect on the application can be severe but the database itself is unharmed. However, if the system fails while a modication is under way, the state of the database is in doubt. Obviously, this can have farreaching implications. Before you delete, insert, or update rows in a database, ask yourself the following questions: Is user access to the database and its tables secure; that is, are specic users given limited database and table-level privileges? Does the modied data preserve the existing integrity of the database? Are systems in place that make the database relatively immune to external events that might cause system or hardware failures?
If you are unable to answer yes to each of these questions, do not panic. Solutions to all these problems are built in to the Informix database servers. After an introduction to the statements that modify data, this chapter discusses these solutions. Chapters 8 through 10 talk about these topics in greater detail.
Modifying Data
4-3
Statements That Modify Data
Statements That Modify Data

The following statements modify data:
s s s
DELETE INSERT UPDATE
Although these SQL statements are relatively simple when compared with the more advanced SELECT statements, use them carefully because they change the contents of the database.
Deleting Rows
The DELETE statement removes any row or combination of rows from a table. You cannot recover a deleted row after the transaction is committed. (Transactions are discussed under Interrupted Modications on page 4-25. For now, think of a transaction and a statement as the same thing.) When deleting a row, you must also be careful to delete any rows of other tables whose values depend on the deleted row. If, however, your database enforces referential constraints, you can use the ON DELETE CASCADE option of the CREATE TABLE or ALTER TABLE statements to allow deletes to cascade from one table in a relationship to another. For more information on referential constraints and the ON DELETE CASCADE option, refer to Referential Integrity on page 4-21.
Deleting All Rows of a Table

The DELETE statement species a table and usually contains a WHERE clause that designates the row or rows that are to be removed from the table. If the WHERE clause is left out, all rows are deleted. Do not execute the following statement:
DELETE FROM customer
4-4
Deleting a Known Number of Rows
Because this DELETE statement does not contain a WHERE clause, all rows from the customer table are deleted. If you attempt an unconditional delete using the DB-Access or INFORMIX-SQL menu options, the program warns you and asks for conrmation. However, an unconditional delete from within a program can occur without warning.

The WHERE clause in a DELETE statement has the same form as the WHERE clause in a SELECT Statement. You can use it to designate exactly which row or rows should be deleted. You can delete a customer with a specic customer number, as shown in the following example:
DELETE FROM customer WHERE customer_num = 175
In this example, because the customer_num column has a unique constraint, you are sure that no more than one row is deleted.
Deleting an Unknown Number of Rows

You can also choose rows based on nonindexed columns, as shown in the following example:
DELETE FROM customer WHERE company = 'Druid Cyclery'
Because the column tested does not have a unique constraint, this statement might delete more than one row. (Druid Cyclery may have two stores, both with the same name but different customer numbers.) You can nd out how many rows might be affected by a DELETE statement by selecting the count of qualifying rows from the customer table for Druid Cyclery.
SELECT COUNT(*) FROM customer WHERE company = 'Druid Cyclery'
You can also select the rows and display them, to be sure they are the ones you want to delete.
Modifying Data
4-5
Using a SELECT statement as a test is only an approximation, however, when the database is available to multiple users concurrently. Between the time you execute the SELECT statement and the subsequent DELETE statement, other users could have modied the table and changed the result. In this example, another user might perform the following actions:
s s s
Insert a new row for another customer named Druid Cyclery Delete one or more of the Druid Cyclery rows before you do so Update a Druid Cyclery row to have a new company name, or update some other customer to have the name Druid Cyclery
Although it is not likely that other users would do these things in that brief interval, the possibility does exist. This same problem affects the UPDATE statement. Ways of addressing this problem are discussed under Concurrency and Locks on page 4-30, and in greater detail in Chapter 7, Programming for a Multiuser Environment. Another problem you may encounter is a hardware or software failure before the statement nishes. In this case, the database may have deleted no rows, some rows, or all specied rows. The state of the database is unknown, which is undesirable. You can prevent this situation by using transaction logging, as discussed in Interrupted Modications on page 4-25.
Complicated Delete Conditions

The WHERE clause in a DELETE statement can be almost as complicated as the one in a SELECT statement. It can contain multiple conditions connected by AND and OR, and it may contain subqueries. Suppose you discover that some rows of the stock table contain incorrect manufacturer codes. Rather than update them, you want to delete them so they can be reentered. You know that these rows, unlike the correct ones, have no matching rows in the manufact table. This allows you to write a DELETE statement such as the one shown in the following example:
DELETE FROM stock WHERE 0 = (SELECT COUNT(*) FROM manufact WHERE manufact.manu_code = stock.manu_code)
The subquery counts the number of rows of manufact that match; the count is 1 for a correct row of stock and 0 for an incorrect one. The latter rows are chosen for deletion.
Inserting Rows
One way to develop a DELETE statement with a complicated condition is to rst develop a SELECT statement that returns precisely the rows to be deleted. Write it as SELECT *; when it returns the desired set of rows, change SELECT * to read DELETE and execute it once more. The WHERE clause of a DELETE statement cannot use a subquery that tests the same table. That is, when you delete from stock, you cannot use a subquery in the WHERE clause that also selects from stock. The key to this rule is in the FROM clause. If a table is named in the FROM clause of a DELETE statement, it cannot also appear in the FROM clause of a subquery of the DELETE statement.
Inserting Rows
The INSERT statement adds a new row, or rows, to a table. The statement has two basic functions: It can create a single new row using column values you supply, or it can create a group of new rows using data selected from other tables.
Single Rows
In its simplest form, the INSERT statement creates one new row from a list of column values, and puts that row in the table. The following statement shows an example of adding a row to the stock table:
INSERT INTO stock VALUES (115, 'PRC', 'tire pump', 108, 'box', '6/box')
The stock table has the following columns:

s s s s s s
stock_num (a number identifying the type of merchandise) manu_code (a foreign key to the manufact table) description (a description of the merchandise) unit_price (the unit price of the merchandise) unit (of measure) unit_descr (characterizing the unit of measure)
Modifying Data
4-7
Inserting Rows
Notice that the values listed in the VALUES clause in the preceding example have a one-to-one correspondence with the columns of this table. To write a VALUES clause, you must know the columns of the tables as well as their sequence from rst to last.
Possible Column Values

The VALUES clause accepts only constant values, not expressions. You can supply the following values:
s s s s s s s s s
Literal numbers Literal datetime values Literal interval values Quoted strings of characters The word NULL for a null value The word TODAY for the current date The word CURRENT for the current date and time The word USER for your user name The word DBSERVERNAME (or SITENAME) for the name of the computer where the database server is running
Some columns of a table might not allow null values. If you attempt to insert
NULL in such a column, the statement is rejected. Or a column in the table
may not permit duplicate values. If you specify a value that is a duplicate of one already in such a column, the statement is rejected. Some columns may even restrict the possible column values allowed. These restrictions are placed on columns using data integrity constraints. For more information on data restrictions, see Database Privileges on page 4-16. Only one column in a table can have the SERIAL data type. The database server generates values for a serial column. To make this happen when you insert values, specify the value zero for the serial column. The database server generates the next actual value in sequence. Serial columns do not allow null values.
4-8
Inserting Rows
You can specify a nonzero value for a serial column (as long as it does not duplicate any existing value in that column) and the database server uses the value. However, that nonzero value may set a new starting point for values that the database server generates. The next value the database server generates for you is one greater than the maximum value in the column. Do not specify the currency symbols for columns that contain money values. Just specify the numeric value of the amount. The database server can convert between numeric and character data types. You can give a string of numeric characters (for example, '-0075.6') as the value of a numeric column. The database server converts the numeric string to a number. An error occurs only if the string does not represent a number. You can specify a number or a date as the value for a character column. The database server converts that value to a character string. For example, if you specify TODAY as the value for a character column, a character string representing the current date is used. (The format used is specied by the DBDATE environment variable.)
Listing Specic Column Names

You do not have to specify values for every column. Instead, you can list the column names after the table name and then supply values for only those columns you named. The following example shows a statement that inserts a new row into the stock table:
INSERT INTO stock (stock_num, description, unit_price, manu_code) VALUES (115, 'tyre pump', 114, 'SHM')
Notice that only the data for the stock number, description, unit price, and manufacturer code is provided. The database server supplies the following values for the remaining columns:
s s
It generates a serial number for an unlisted serial column. It generates a default value for a column with a specic default associated with it. It generates a null value for any column that allows nulls but does not specify a default value for any column that species null as the default value.
Modifying Data
4-9
Inserting Rows
This means that you must list and supply values for all columns that do not specify a default value or do not permit nulls. However, you can list the columns in any orderas long as the values for those columns are listed in the same order. For information about setting a default value for a column, see Chapter 9, Implementing Your Data Model. After the INSERT statement is executed, the following new row is inserted into the stock table:
stock_num 115 manu_code description SHM tyre pump unit_price 114 unit unit_descr
Both the unit and unit_descr are blank, indicating that null values are in those two columns. Because the unit column permits nulls, one can only guess the number of tire pumps that were purchased for $114. Of course, if a default value of box was specied for this column, then box would be the unit of measure. In any case, when inserting values into specic columns of a table, pay attention to what data is needed for that row.
Multiple Rows and Expressions

The other major form of the INSERT statement replaces the VALUES clause with a SELECT statement. This feature allows you to insert the following data:
s
Multiple rows with only one statement (a row is inserted for each row returned by the SELECT statement) Calculated values (the VALUES clause only permits constants) because the select list can contain expressions
For example, suppose a follow-up call is required for every order that has been paid for but not shipped. The INSERT statement in the following example nds those orders and inserts a row in cust_calls for each order:
INSERT INTO cust_calls (customer_num, call_descr) SELECT customer_num, order_num FROM orders WHERE paid_date IS NOT NULL AND ship_date IS NULL
4-10
Inserting Rows
This SELECT statement returns two columns. The data from these columns (in each selected row) is inserted into the named columns of the cust_calls table. Then, an order number (from order_num, a serial column) is inserted into the call description, which is a character column. Remember that the database server allows you to insert integer values into a character column. It automatically converts the serial number to a character string of decimal digits.
Restrictions on the Insert-Selection

The following list contains the restrictions on the SELECT statement for inserting rows:
s s s s
It cannot contain an INTO clause. It cannot contain an INTO TEMP clause. It cannot contain an ORDER BY clause. It cannot refer to the table into which you are inserting rows.
The INTO, INTO TEMP, and ORDER BY clause restrictions are minor. The INTO clause is not useful in this context. (It is discussed in Chapter 5, Programming with SQL.) You can work around the INTO TEMP clause restriction by rst selecting the data you want to insert into a temporary table and then inserting the data from the temporary table with the INSERT statement. Likewise, the lack of an ORDER BY clause is not important. If you need to ensure that the new rows are physically ordered in the table, you can rst select them into a temporary table and order it, and then insert from the temporary table. You can also apply a physical order to the table using a clustered index after all insertions are done. The last restriction is more serious because it prevents you from naming the same table in both the INTO clause of the INSERT statement and the FROM clause of the SELECT statement. (This saves the database server from getting into an endless loop in which each inserted row is reselected and reinserted.) In some cases, however, you may want to do this. For example, suppose that you have learned that the Nikolus company supplies the same products as the Anza company, but at half the price. You want to add rows to the stock table to reect this. Optimally, you want to select data from all the Anza stock rows and reinsert it with the Nikolus manufacturer code. However, you cannot select from the same table into which you are inserting.
Modifying Data
4-11
Updating Rows
You can get around this restriction by selecting the data you want to insert into a temporary table. Then, select from that table in the INSERT statement. The following statements are required to accomplish this:
SELECT stock_num, 'HSK' temp_manu, description, unit_price/2 half_price, unit, unit_descr FROM stock WHERE manu_code = 'ANZ' AND stock_num < 110 INTO TEMP anzrows; INSERT INTO stock SELECT * FROM anzrows; DROP TABLE anzrows;
This SELECT statement takes existing rows from stock and substitutes a literal value for the manufacturer code and a computed value for the unit price. These rows are then saved in a temporary table, anzrows, which is immediately inserted into the stock table. When you insert multiple rows, a risk exists that one of the rows contains invalid data that might cause the database server to report an error. When this happens, the statement terminates early. Even if no error occurs, a very small risk exists that there might be a hardware or software failure while the statement is executing (for example, the disk might ll up). In either event, you cannot easily tell how many new rows were inserted. If you repeat the statement in its entirety, you might create duplicate rowsor you might not. Because the database is in an unknown state, you cannot know what to do. The answer lies in using transactions, as discussed in Interrupted Modications on page 4-25.
Updating Rows
You use the UPDATE statement to change the contents of one or more columns in one or more existing rows of a table. This statement takes two fundamentally different forms. One lets you assign specic values to columns by name; the other lets you assign a list of values (that might be returned by a SELECT statement) to a list of columns. In either case, if you are updating rows and some of the columns have data integrity constraints, the data you change must be within the constraints placed on those columns. For more information, refer to Database Privileges on page 4-16.
4-12
Updating Rows Selecting Rows to Update

Either form of the UPDATE statement can end with a WHERE clause that determines which rows are modied. If you omit it, all rows are modied. The WHERE clause can be quite complicated to select the precise set of rows that need changing. The only restriction on it is that the table that you are updating cannot be named in the FROM clause of a subquery. The rst form of an UPDATE statement uses a series of assignment clauses to specify new column values, as shown in the following example:
UPDATE customer SET fname = 'Barnaby', lname = 'Dorfler' WHERE customer_num = 103
The WHERE clause selects the row to be updated. In the stores7 database, the customer.customer_num column is the primary key for that table, so this statement can update no more than one row. You can also use subqueries in the WHERE clause. Suppose that the Anza Corporation issues a safety recall of their tennis balls. As a result, any unshipped orders that include stock number 6 from manufacturer ANZ must be put on back order, as shown in the following example:
UPDATE orders SET backlog = 'y' WHERE ship_date IS NULL AND order_num IN (SELECT DISTINCT items.order_num FROM items WHERE items.stock_num = 6 AND items.manu_code = 'ANZ')
This subquery returns a column of order numbers (zero or more). The UPDATE operation then tests each row of orders against the list and performs the update if that row matches.
Modifying Data
4-13
Updating Rows Updating with Uniform Values

Each assignment after the keyword SET species a new value for a column. That value is applied uniformly to every row that you update. In the examples in the previous section, the new values were constants, but you can assign any expression, including one based on the column value itself. Suppose the manufacturer code HRO has raised all prices by 5 percent, and you must update the stock table to reect this. You would use a statement such as the one shown in the following example:
UPDATE stock SET unit_price = unit_price * 1.05 WHERE manu_code = 'HRO'
You can also use a subquery as part of the assigned value. When a subquery is used as an element of an expression, it must return exactly one value (one column and one row). Suppose that you decide that for any stock number, you must charge a higher price than any manufacturer of that product. You need to update the prices of all unshipped orders. The SELECT statements in the following example specify the criteria:
UPDATE items SET total_price = quantity * (SELECT MAX (unit_price) FROM stock WHERE stock.stock_num = items.stock_num) WHERE items.order_num IN (SELECT order_num FROM orders WHERE ship_date IS NULL)
The rst SELECT statement returns a single valuethe highest price in the stock table for a particular product. This is a correlated subquery; because when a value from items appears in its WHERE clause, you must execute it for every row that you update. The second SELECT statement produces a list of the order numbers of unshipped orders. It is an uncorrelated subquery that is executed once.
4-14
Updating Rows Impossible Updates

Restrictions exist on the use of subqueries when you modify data. In particular, you cannot query the table that is being modied. You can refer to the present value of a column in an expression, as in the example in which the unit_price column was incremented by 5 percent. You can refer to a value of a column in a WHERE clause in a subquery, as in the example that updated the stock table, in which the items table is updated and items.stock_num is used in a join expression. The need to update and query a table at the same time does not occur often in a well-designed database. (Database design is covered in Chapter 8 and Chapter 9.) However, you may want to update and query at the same time when a database is rst being developed, before its design has been carefully thought through. A typical problem arises when a table inadvertently and incorrectly contains a few rows with duplicate values in a column that should be unique. You might want to delete the duplicate rows or update only the duplicate rows. Either way, a test for duplicate rows inevitably requires a subquery, which is not allowed in an UPDATE statement or DELETE statement. Chapter 6, Modifying Data Through SQL Programs, discusses how to use an update cursor to perform this kind of modication.
Updating with Selected Values

The second form of UPDATE statement replaces the list of assignments with a single bulk assignment, in which a list of columns is set equal to a list of values. When the values are simple constants, this form is nothing more than the form of the previous example with its parts rearranged, as shown in the following example:
UPDATE customer SET (fname, lname) = ('Barnaby', 'Dorfler') WHERE customer_num = 103
No advantage exists to writing the statement this way. In fact, it is harder to read because it is not obvious which values are assigned to which columns.
Modifying Data
4-15
Database Privileges
However, when the values to be assigned come from a single SELECT statement, this form makes sense. Suppose that changes of address are to be applied to several customers. Instead of updating the customer table each time a change is reported, the new addresses are collected in a single temporary table named newaddr. It contains columns for the customer number and the address-related elds of the customer table. Now the time comes to apply all the new addresses at once.
UPDATE customer SET (address1, address2, city, state, zipcode) = ((SELECT address1, address2, city, state, zipcode FROM newaddr WHERE newaddr.customer_num=customer.customer_num)) WHERE customer_num IN (SELECT customer_num FROM newaddr)
Notice that the values for multiple columns are produced by a single SELECT statement. If you rewrite this example in the other form, with an assignment for each updated column, you must write ve SELECT statements, one for each column to be updated. Not only is such a statement harder to write but it also takes much longer to execute.
Tip: In NewEra, INFORMIX-4GL, and the SQL API programs, you can use record or host variables to update values. For more information, refer to Chapter 5, Programming with SQL.
Database Privileges
Two levels of privileges exist in a database: database-level privileges and table-level privileges. When you create a database, you are the only one who can access it until you, as the owner (or Database Administrator [DBA]) of the database, grant database-level privileges to others. When you create a table in a database that is not ANSI-compliant, all users have access privileges to the table until you, as the owner of the table, revoke table-level privileges from specic users.
4-16
Database Privileges
The following list contains database-level privileges: Connect privilege Resource privilege DBA privilege allows you to open a database, issue queries, and create and place indexes on temporary tables. allows you to create permanent tables. allows you to perform several additional functions as the DBA.
Seven table-level privileges exist. However, only the rst four are covered here: Select privilege is granted on a table-by-table basis and allows you to select rows from a table (This privilege can be limited by specic columns in a table.) allows you to delete rows. allows you to insert rows. allows you to update existing rows (that is, to change their content).
Delete privilege Insert privilege Update privilege
The people who create databases and tables often grant the Connect and Select privileges to public so that all users have them. If you can query a table, you have at least the Connect and Select privileges for that database and table. For more information about public, see The Users and the Public on page 10-7. You need the other table-level privileges to modify data. The owners of tables often withhold these privileges or grant them only to specic users. As a result, you may not be able to modify some tables that you can query freely. Because these privileges are granted on a table-by-table basis, you can have only Insert privileges on one table and only Update privileges on another, for example. The Update privileges can be restricted even further to specic columns in a table. Chapter 10, Granting and Limiting Access to Your Database, discusses granting privileges from the standpoint of the DBA. A complete list of privileges and a summary of the GRANT and REVOKE statements can be found in Chapter 1 of the Informix Guide to SQL: Syntax.
Modifying Data
4-17
Displaying Table Privileges
Displaying Table Privileges

If you are the owner of a table (that is, if you created it), you have all privileges on that table. Otherwise, you can determine the privileges you have for a certain table by querying the system catalog. The system catalog consists of system tables that describe the database structure. The privileges granted on each table are recorded in the systabauth system table. To display these privileges, you must also know the unique identier number of the table. This number is specied in the systables system table. So, to display privileges granted on the orders table, you might enter the following SELECT statement:
SELECT * FROM systabauth WHERE tabid = (SELECT tabid FROM systables WHERE tabname = 'orders')
The output of the query resembles the following display:
grantor tfecit tfecit tfecit
grantee mutator procrustes public
tabid 101 101 101
tabauth su-i-x-s--idx-s--i-x--
The grantor is the user who grants the privilege. The grantor is usually the owner of the table but can be another user empowered by the grantor. The grantee is the user to whom the privilege is granted, and the grantee public means any user with Connect privilege. If your user name does not appear, you have only those privileges granted to public. The tabauth column species the privileges granted. The letters in each row of this column are the initial letters of the privilege names except that i means Insert and x means Index. In this example, public has Select, Insert, and Index privileges. Only the user mutator has Update privileges, and only the user procrustes has Delete privileges. Before the database server performs any action for you (for example, execute a DELETE statement), it performs a query similar to the preceding one. If you are not the owner of the table, and if it cannot nd the necessary privilege on the table for your user name or for public, it refuses to perform the operation.
4-18
Data Integrity
Data Integrity
The INSERT, UPDATE, and DELETE statements modify data in an existing database. Whenever you modify existing data, the integrity of the data can be affected. For example, an order for a nonexistent product could be entered into the orders table, a customer with outstanding orders could be deleted from the customer table, or the order number could be updated in the orders table and not in the items table. In each of these cases, the integrity of the stored data is lost. Data integrity is actually made up of the following parts:
s
Entity integrity Each row of a table has a unique identier. Semantic integrity The data in the columns properly reects the types of information the column was designed to hold.
Referential integrity The relationships between tables are enforced.
Well-designed databases incorporate these principles so that when you modify data, the database itself prevents you from doing anything that might harm the data integrity.
Entity Integrity
An entity is any person, place, or thing to be recorded in a database. Each entity represents a table, and each row of a table represents an instance of that entity. For example, if order is an entity, the orders table represents the idea of order and each row in the table represents a specic order. To identify each row in a table, the table must have a primary key. The primary key is a unique value that identies each row. This requirement is called the entity integrity constraint.
Modifying Data
4-19
Semantic Integrity
For example, the orders table primary key is order_num. The order_num column holds a unique system-generated order number for each row in the table. To access a row of data in the orders table, you can use the following SELECT statement:
SELECT * FROM orders WHERE order_num = 1001
Using the order number in the WHERE clause of this statement enables you to access a row easily because the order number uniquely identies that row. If the table allowed duplicate order numbers, it would be almost impossible to access one single row, because all other columns of this table allow duplicate values. Refer to Chapter 8, Building Your Data Model, for more information on primary keys and entity integrity.
Semantic Integrity
Semantic integrity ensures that data entered into a row reects an allowable value for that row. This means that the value must be within the domain, or allowable set of values, for that column. For example, the quantity column of the items table permits only numbers. If a value outside the domain can be entered into a column, the semantic integrity of the data is violated. Semantic integrity is enforced using the following constraints:
s
Data type The data type denes the types of values that you can store in a column. For example, the data type SMALLINT allows you to enter values from -32,767 to 32,767 into a column.
Default value The default value is the value inserted into the column when an explicit value is not specied. For example, the user_id column of the cust_calls table defaults to the login name of the user if no name is entered.
4-20
Referential Integrity
Check constraint The check constraint species conditions on data inserted into a column. Each row inserted into a table must meet these conditions. For example, the quantity column of the items table may check for quantities greater than or equal to one. For more information on using semantic integrity constraints in database design, refer to Dening the Domains on page 9-3.
Referential integrity refers to the relationship between tables. Because each table in a database must have a primary key, it is possible that this primary key appears in other tables because of its relationship to data within those tables. When a primary key from one table appears in another table, it is called a foreign key. Foreign keys join tables and establish dependencies between tables. Tables can form a hierarchy of dependencies in such a way that if you change or delete a row in one table, you destroy the meaning of rows in other tables. For example, Figure 4-1 on page 4-22 shows that the customer_num column of the customer table is a primary key for that table and a foreign key in the orders and cust_call tables. Customer number 106, George Watson, is referenced in both the orders and cust_calls tables. If customer 106 is deleted from the customer table, the link between the three tables and this particular customer is destroyed. When you delete a row containing a primary key or update it with a different primary key, you destroy the meaning of any rows that contain that value as a foreign key. Referential integrity is the logical dependency of a foreign key on a primary key. The integrity of a row that contains a foreign key depends on the integrity of the row that it referencesthe row that contains the matching primary key.
Modifying Data
4-21
By default, INFORMIX-OnLine Dynamic Server does not allow you to violate referential integrity and gives you an error message if you attempt to delete rows from the parent table before you delete rows from the child table. You can, however, use the ON DELETE CASCADE option to cause deletes from a parent table to trip deletes on child tables. See Using the ON DELETE CASCADE Option on page 4-23.
Figure 4-1 Referential integrity in the stores7 database
customer Table (detail) customer_num 103 106 fname Philip George lname Currie Watson
orders Table (detail) order_num 1002 1003 1004 order_date 05/21/1994 05/22/1994 05/22/1994 customer_num 101 104 106
cust_calls Table (detail) customer_num 106 110 119 call_dtime 1994-06-12 8:20 1994-07-07 10:24 1994-07-01 15:00 user_id maryj richc richc
4-22
You can dene primary and foreign keys, and the relationship between them, using the CREATE TABLE and ALTER TABLE statements. For more information on these statements, see Chapter 1 of the Informix Guide to SQL: Syntax. For information on building data models using primary and foreign keys, refer to Chapter 8, Building Your Data Model.
Using the ON DELETE CASCADE Option

You can maintain referential integrity when deleting rows from a primary key for a table by using the ON DELETE CASCADE option in the REFERENCES clause of the CREATE TABLE and ALTER TABLE statements. This option allows you to delete a row from a parent table and its corresponding rows in matching child tables with a single delete command.
Locking During Cascading Deletes

During deletes, locks are held on all qualifying rows of the parent and child tables. When you specify a delete, the delete requested from the parent table occurs before any referential actions are performed.
What Happens to Multiple Children Tables

If you have a parent table with two child constraints, one child with cascading deletes specied and one child without cascading deletes, and you attempt to delete a row from the parent table that applies to both child tables, then the DELETE statement fails and no rows are deleted from either the parent or child tables.
Logging Must Be Turned On

You must turn logging on in your current database for cascading deletes to work. Logging and cascading deletes are discussed in Transaction Logging on page 4-26.
Modifying Data
4-23
Referential Integrity Example

Say you have two tables with referential integrity rules applied, a parent table, accounts, and a child table, sub_accounts. The following CREATE TABLE statements dene the referential constraints:
CREATE TABLE accounts ( acc_num SERIAL primary key, acc_type INT, acc_descr CHAR(20)); CREATE TABLE sub_accounts ( sub_acc INTEGER primary key, ref_num INTEGER REFERENCES references accounts (acc_num) ON DELETE CASCADE, sub_descr CHAR(20));
Notice that the primary key of the accounts table, the acc_num column, uses a SERIAL data type, and the foreign key of the sub_accounts table, the ref_num column, uses an INTEGER data type. Combining the SERIAL data type on the primary key and the INTEGER data type on the foreign key is allowed. This is the only condition where you can mix and match data types. The SERIAL data type is an INTEGER and the values for the column are automatically generated by the database. All other primary and foreign key combinations must match explicitly. For example, a primary key dened as CHAR must match a foreign key dened as CHAR. To delete a row from the accounts table that will cascade a delete to the sub_accounts table, you must turn on logging. After logging is turned on, you can delete the account number 2 from both tables, as shown in the following example:
DELETE FROM accounts WHERE acc_num = 2
Restrictions on Cascading Deletes

You can use cascading deletes for most deletes, including deletes on selfreferencing and cyclic queries. The only exception is correlated subqueries. In correlated subqueries, the subquery (or inner SELECT) is correlated when the value it produces depends on a value produced by the outer SELECT statement that contains it. If you have implemented cascading deletes, you cannot write deletes that use a child table in the correlated subquery. You receive an error when you attempt to delete from a correlated subquery.
4-24
Interrupted Modications
Interrupted Modications
Even if all the software is error-free and all the hardware is utterly reliable, the world outside the computer can interfere. It is possible for lightning to strike the building, interrupting the electrical supply and stopping the computer in the middle of your UPDATE statement. It is more likely, however, that a disk lls up or a user supplies incorrect data, causing your multirow insert to stop early with an error. In any case, as you are modifying data, you must assume that some unforeseen event can interrupt the modication. When a modication is interrupted by an external cause, you cannot be sure how much of the operation was completed. Even in a single-row operation, you cannot know whether the data reached the disk or the indexes were properly updated. If multirow modications are a problem, multistatement ones are worse. It does not help that they are usually embedded in programs so that you do not see the individual SQL statements being executed. For example, the job of entering a new order in the stores7 database requires you to perform the following steps:
s s
Insert a row in the orders table. (This generates an order number.) For each item ordered, insert a row in the items table.
Two ways to program an order-entry application exist. One way is to make it completely interactive so that the program inserts the rst row immediately, and then inserts each item as the user enters data. This is the wrong approach because it exposes the operation to the possibility of many more unforeseen events: the customers telephone disconnecting, the user pressing the wrong key, the users terminal or computer losing power, and so on. The right way to build an order-entry application is described in the following list:
s s
Accept all the data interactively Validate the data and expand it (by looking up codes in stock and manufact, for example) Display the information on the screen for inspection Wait for the operator to make a nal commitment Perform the insertions quickly
Modifying Data 4-25
s s s
The Transaction
Even when this is done, sometimes an unforeseen circumstance can halt the program after it inserts the order but before it nishes inserting the items. If that happens, the database is in an unpredictable condition: its data integrity is compromised.
The Transaction
The solution to all these potential problems is called the transaction. A transaction is a sequence of modications that either must be accomplished completely or not at all. The database server guarantees that operations performed within the bounds of a transaction are either completely and perfectly committed to disk, or the database is restored to the state it was in before the transaction started. The transaction is not merely protection against unforeseen failures; it also offers a program a way to escape when the program detects a logical error. (This is discussed further in Chapter 6, Modifying Data Through SQL Programs.)
Transaction Logging
The database server can keep a record of each change that it makes to the database during a transaction. If something happens to cancel the transaction, the database server automatically uses the records to reverse the changes. Many things can make a transaction fail. The program that issues the SQL statements can crash or be terminated, or there might be a hardware or software failure in any other component of the system. As soon as the database server discovers that the transaction failed, which might be only after the computer and the database server are restarted, it returns the database to the state it was in before the transaction began using the records from the transaction. The process of keeping records of transactions is called transaction logging, or simply logging. The records of the transactions, called log records, are stored in a portion of disk space separate from the database. In INFORMIX-OnLine Dynamic Server, this space is called the logical log (because the log records represent logical units of the transactions). In INFORMIX-SE, the space used to store log records is called the transaction log le.
4-26
Specifying Transactions
Databases do not generate transaction records automatically. The database administrator decides whether to make a database use transaction logging. Without transaction logging, you cannot roll back transactions.
Logging and Cascading Deletes

Logging must be turned on in your database for cascading deletes to work because when you specify a cascading delete, the delete is rst performed on the primary key of the parent table. If the system crashes after the rows of the primary key of the parent table are performed but before the rows of the foreign key of the child table are deleted, referential integrity is violated. If logging is turned off, even temporarily, deletes do not cascade. After logging is turned back on, however, deletes can cascade again. Turn logging on with the CREATE DATABASE statement for OnLine database servers.
Specifying Transactions
The boundaries of transactions are specied with SQL statements. You can do this in two ways. In the most common style, you specify the start of a multistatement transaction by executing the BEGIN WORK statement. In databases that are created with the MODE ANSI option, no need exists to mark the beginning of a transaction. One is always in effect; you indicate only the end of each transaction. In both styles, you specify the end of a successful transaction by executing the COMMIT WORK statement. This statement tells the database server that you reached the end of a series of statements that must succeed together. The database server does whatever is necessary to make sure that all modications are properly completed and committed to disk. It is also possible for a program to cancel a transaction deliberately. It does so by executing the ROLLBACK WORK statement. This statement asks the database server to cancel the current transaction and undo any changes. For example, an order-entry application can use a transaction when creating a new order in the following ways:
s s s
Accept all data interactively Validate and expand it Wait for the operator to make a nal commitment
Modifying Data 4-27
Archives and Logs
s s
Execute BEGIN WORK Insert rows in the orders and items tables, checking the error code returned by the database server If there were no errors, execute COMMIT WORK, otherwise execute
ROLLBACK WORK
If any external failure prevents the transaction from being completed, the partial transaction rolls back when the system restarts. In all cases, the database is in a predictable state: Either the new order is completely entered, or it is not entered at all.
Archives and Logs

By using transactions, you can ensure that the database is always in a consistent state and that your modications are properly recorded on disk. But the disk itself is not perfectly safe. It is vulnerable to mechanical failures and to ood, re, and earthquake. The only safeguard is to keep multiple copies of the data. These redundant copies are called archive copies. The transaction log (also called the logical log) complements the archive copy of a database. Its contents are a history of all modications that occurred since the last time the database was archived. If it should ever be necessary to restore the database from the archive copy, the transaction log can be used to roll the database forward to its most recent state.
Archiving with INFORMIX-SE

If a database is stored in operating system les (INFORMIX-SE), archive copies are made using the normal methods for making backup copies in your operating system. Only two special considerations exist for databases. The rst is a practical consideration: A database can grow to great size. It may become the largest le or set of les in the system. It can also be awkward or very time consuming to make a copy of it. You may need a special procedure for copying the database, separate from the usual backup procedures, and the job may not be done too frequently.
4-28
Archiving with INFORMIX-OnLine Dynamic Server
The second consideration is the special relationship between the database and the transaction log le. An archive copy is an image of the database at one instant. The log le contains the history of modications that were made during that instant. It is important that those two instants are identical; in other words, it is important to start a new transaction log le immediately upon making an archive copy of the database. Then, if you must restore the database from the archive tape, the transaction log contains exactly the history needed to bring it forward in time from that instant to the latest update. The statement that applies a log to a restored database is ROLLFORWARD DATABASE. You start a new log le by using whatever operating system commands are needed to delete the le and re-create it empty or simply to set the length of the le to zero. A transaction log le can grow to extreme size. If you update a row ten times, just one row exists in the databasebut ten update events are recorded in the log le. If the size of the log le is a problem, you can start a fresh log. Choose a time when the database is not being updated (so no transactions are active), and copy the existing log to another medium. That copy represents all modications for some period of time; preserve it carefully. Then start a new log le. If you ever have to restore the database, you must apply all the log les in their correct sequence.
Archiving with INFORMIX-OnLine Dynamic Server

The OnLine database server contains elaborate features to support archiving and logging. They are described in the INFORMIX-OnLine Dynamic Server Archive and Backup Guide. Conceptually, the facilities of OnLine are similar to those already described for INFORMIX-SE, but they are more elaborate for the following reasons:
s
OnLine has very stringent requirements for performance and reliability (for example, it supports making archive copies while databases are in use). OnLine manages its own disk space, which is devoted to logging. It performs logging concurrently for all databases using a limited set of log les. The log les can be copied to another medium (backed up) while transactions are active.
Modifying Data 4-29
s s
Concurrency and Locks
These facilities are usually managed from a central location by the OnLine administrator, so database users never have to be concerned with them. If you want to make a personal archive copy of a single database or table that is held by OnLine, you can do it with the onunload utility. This program copies a table or a database to tape. Its output consists of binary images of the disk pages as they were stored in OnLine. As a result, the copy can be made very quickly, and the corresponding onload program can restore the le very quickly. However, the data format is not meaningful to any other programs. If your OnLine administrator is using ON-Archive to create archives and back up logical logs, you may also be able to create your own backup copies using ON-Archive. See your INFORMIX-OnLine Dynamic Server Archive and Backup Guide for more information.
Concurrency and Locks

If your database is contained in a single-user workstation, without a network connecting it to other computers, concurrency is unimportant. In all other cases, you must allow for the possibility that, while your program is modifying data, another program is also reading or modifying the same data. This is concurrency: two or more independent uses of the same data at the same time. A high level of concurrency is crucial to good performance in a multiuser database system. Unless controls exist on the use of data, however, concurrency can lead to a variety of negative effects. Programs could read obsolete data; modications could be lost even though it seems they were entered successfully. The database server prevents errors of this kind by imposing a system of locks. A lock is a claim, or reservation, that a program can place on a piece of data. The database server guarantees that, as long as the data is locked, no other program can modify it. When another program requests the data, the database server either makes the program wait or turns it back with an error.
4-30
Data Replication
You use a combination of SQL statements to control the effect that locks have on your data access: SET LOCK MODE and either SET ISOLATION or SET TRANSACTION. You can understand the details of these statements after reading a discussion on the use of cursors from within programs. Cursors are covered in Chapter 5, Programming with SQL, and Chapter 6, Modifying Data Through SQL Programs. Also see Chapter 7, Programming for a Multiuser Environment, for more information about locking and concurrency.
Data Replication
Data replication, in the broadest sense of the term, is when database objects have more than one representation at more than one distinct site. For example, a database that is copied to a database server on a different computer so that reports can be run against the data without disturbing client applications using the original databaseis one way data can be replicated. The following list describes the advantages of data replication:
s
Clients accessing replicated data locallyas opposed to remote data that is not replicatedexperience improved performance because they do not have to use network services. Clients at all sites experience improved availability with replicated data, because if local replicated data is unavailable, a copy of the data is still available, albeit remotely.
These advantages do not come without a cost. Data replication obviously requires more storage for replicated data than for unreplicated data, and updating replicated data can take more processing time than updating a single object. Data replication can actually be implemented in the logic of client applications, by explicitly specifying where data should be found or updated. However, this way of achieving data replication is costly, errorprone, and difcult to maintain. Instead, the concept of data replication is often coupled with replication transparency. Replication transparency is functionality built into a database server (instead of client applications) to automatically handle the details of locating and maintaining data replicas.
Modifying Data
4-31
INFORMIX-OnLine Dynamic Server Data Replication
INFORMIX-OnLine Dynamic Server Data Replication

Within the broad framework of data replication, OnLine implements nearly transparent data replication of entire database servers. All the data managed by one OnLine database server is replicated and dynamically updated on another OnLine database server, usually at a remote site. OnLine data replication is sometimes called hot site backup, because it provides a means of maintaining a backup copy of the entire database server that can be used quickly in the event of a catastrophic failure. Because OnLine provides replication transparency, you generally do not need to be concerned with or aware of data replication; the OnLine administrator takes care of it. However, if your organization decides to use data replication, you should be aware that special connectivity considerations exist for client applications in a data replication environment. These considerations are described in the INFORMIX-OnLine Dynamic Server Administrators Guide.
Summary
Database access is regulated by the privileges that the database owner grants to you. The privileges that let you query data are often granted automatically, but the ability to modify data is regulated by specic Insert, Delete, and Update privileges that are granted on a table-by-table basis. If data integrity constraints are imposed on the database, your ability to modify data is restricted by those constraints. Your database- and table-level privileges, along with any data constraints, control how and when you can modify data. You can delete one or more rows from a table with the DELETE statement. Its WHERE clause selects the rows; use a SELECT statement with the same clause to preview the deletes. Rows are added to a table with the INSERT statement. You can insert a single row containing specied column values, or you can insert a block of rows generated by a SELECT statement.
4-32
Summary
You use the UPDATE statement to modify the contents of existing rows. You specify the new contents with expressions that can include subqueries, so that you can use data based on other tables or the updated table itself. The statement has two forms: in the rst form you specify new values column by column; you use the other form when the new values are generated as a set from a SELECT statement or a record variable. You use the REFERENCES clause of the CREATE TABLE and ALTER TABLE statements to create relationships between tables. The ON DELETE CASCADE option of the REFERENCES clause allows you to delete rows from parent and associated child tables with one DELETE statement. You use transactions to prevent unforeseen interruptions in a modication from leaving the database in an indeterminate state. When modications are performed within a transaction, they are rolled back following an error. The transaction log also extends the periodically made archive copy of the database, so that if the database must be restored, it can be brought back to its most recent state. Data replication, which is transparent to users, offers another type of protection from catastrophic failures.
Modifying Data
4-33
Chapter
Programming with SQL
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 5-4 5-5 5-5 5-5 5-6 5-8 5-9 5-12 5-12 5-13 5-13 5-13 5-14 5-14 5-16 5-17 5-18 5-18 5-18 5-18 5-19 5-19 5-21 5-21 5-22 5-23 5-23 5-24
SQL in Programs . . . . . . . . . SQL in SQL APIs . . . . . . . . SQL in Application Languages . . . Static Embedding . . . . . . . . Dynamic Statements . . . . . . . Program Variables and Host Variables . Calling the Database Server . . . The SQL Communications Area The SQLCODE Field . . . . End of Data . . . . . . Negative Codes . . . . The SQLERRD Array . . . . The SQLWARN Array . . . The SQLSTATE Value . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
Retrieving Single Rows . . . . . . . . . . . . . . . Data Type Conversion . . . . . . . . . . . . . . Dealing with Null Data . . . . . . . . . . . . . . Dealing with Errors . . . . . . . . . . . . . . . End of Data . . . . . . . . . . . . . . . . . End of Data with Databases that Are Not ANSI-Compliant Serious Errors . . . . . . . . . . . . . . . . Interpreting End of Data with Aggregate Functions . . . Using Default Values . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
Retrieving Multiple Rows . . . . . . . . . . . . . . . . Declaring a Cursor . . . . . . . . . . . . . . . . . Opening a Cursor . . . . . . . . . . . . . . . . . . Fetching Rows . . . . . . . . . . . . . . . . . . . Detecting End of Data . . . . . . . . . . . . . . . Locating the INTO Clause. . . . . . . . . . . . . .
Cursor Input Modes . . . . . . . . The Active Set of a Cursor . . . . . . Creating the Active Set . . . . . . The Active Set for a Sequential Cursor The Active Set for a Scroll Cursor . . The Active Set and Concurrency . . Using a Cursor: A Parts Explosion . . . Dynamic SQL . . . . . . . . . . . Preparing a Statement . . . . . . Executing Prepared SQL. . . . . . Using Prepared SELECT Statements Dynamic Host Variables . . . . . . Freeing Prepared Statements . . . . Quick Execution . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
5-24 5-25 5-25 5-26 5-26 5-27 5-28 5-30 5-31 5-33 5-34 5-35 5-36 5-36 5-36 5-37 5-40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Embedding Data Denition Statements . . . Embedding Grant and Revoke Privileges . Summary . . . . . . . . . . . . .
5-2
n the examples in the previous chapters, SQL is treated as if it were an interactive computer language; that is, as if you could type a SELECT statement directly into the database server and see rows of data rolling back to you. Of course, that is not how things are. Many layers of software stand between you and the database server. The database server retains data in a binary form that must be formatted before it can be displayed. It does not return a mass of data at once; it returns one row at a time, as a program requests it. You can access information in your database in two ways: through interactive access using DB-Access or INFORMIX-SQL or through application programs written using an SQL API, or through an application language such as NewEra or INFORMIX-4GL. Almost any program can contain SQL statements, execute them, and retrieve data from a database server. This chapter explains how these activities are performed and indicates how you can write programs that perform them. This chapter is only an introduction to the concepts that are common to SQL programming in any language. Before you can write a successful program in a particular programming language, you must rst become uent in that language. Then, because the details of the process are slightly different in every language, you must become familiar with the manual for the Informix SQL API specic to that language or your NewEra OR INFORMIX-4GL documentation.
Programming with SQL 5-3
SQL in Programs
SQL in Programs
You can write a program in any of several languages and mix SQL statements in among the other statements of the program, just as if they were ordinary statements of that programming language. The SQL statements are said to be embedded in the program, and the program is said to contain embedded SQL, often abbreviated by Informix as ESQL.
SQL in SQL APIs

ESQL products are Informix SQL APIs.Informix produces SQL APIs for the fol-
lowing programming languages:

s s s s
C COBOL FORTRAN (pre-Version 6.0)
Ada (Version 4.0 only)
All SQL API products work in a similar way, as shown in Figure 5-1. You write a source program in which you treat SQL statements as executable code. Your source program is processed by an embedded SQL preprocessor, a program that locates the embedded SQL statements and converts them into a series of procedure calls and special data structures.
Figure 5-1 Overview of processing a program with embedded SQL statements
ESQL source program
ESQL preprocessor
Source program with procedure calls
Language compiler
Executable program
5-4
SQL in Application Languages
The converted source program then passes through the programming language compiler. The compiler output becomes an executable program after it is linked with a library of SQL API procedures. When the program runs, the SQL API library procedures are called; they set up communications with the database server to carry out the SQL operations.
SQL in Application Languages

Whereas SQL API products allow you to embed SQL in the host language, some languages have SQL as a natural part of their statement set. INFORMIX-4GL incorporates the SQL language as a natural part of the fourthgeneration language it supports. The NewEra product provides support for embedded SQL, and it also provides a mechanism called a SuperTable for automatically generating SQL statements needed to access a table being displayed. Informix Stored Procedure Language (SPL) also uses SQL as a natural part of its statement set. You use INFORMIX-4GL or an SQL API product to write application programs. You use SPL to write procedures that are stored with a database and are called from an application program.
Static Embedding
You can introduce SQL statements into a program in two ways. The simpler and more common way is by static embedding, which means that the SQL statements are written as part of the source program text. The statements are static because they are a xed part of the source text.
Dynamic Statements
Some applications require the ability to compose SQL statements in response to user input. For example, a program might have to select different columns or apply different criteria to rows, depending on what the user wants. This can be done with dynamic SQL, in which the program composes an SQL statement as a string of characters in memory and passes it to the database server to be executed. Dynamic statements are not part of the program source text; they are constructed in memory during execution. In NewEra, much of the database interation is done with dynamically executed SQL statements.
Program Variables and Host Variables

Application programs can use program variables within SQL statements. In NewEra, INFORMIX-4GL and SPL, you put the program variable in the SQL statement as syntax allows. For example, a DELETE statement can use a program variable in its WHERE clause. Figure 5-2 shows a program variable in INFORMIX-4GL.
MAIN . . . DEFINE drop_number INT LET drop_number = 108 DELETE FROM items WHERE order_num = drop_number . . .
Figure 5-2 Using a program variable in INFORMIX-4GL
Figure 5-3 shows a program variable in SPL.

CREATE PROCEDURE delete_item (drop_number INT) . . . DELETE FROM items WHERE order_num = drop_number . . .
Figure 5-3 Using a program variable in SPL
In applications that use embedded SQL statements, the SQL statements can refer to the contents of program variables. A program variable that is named in an embedded SQL statement is called a host variable because the SQL statement is thought of as being a guest in the program.
5-6
The following example is a DELETE statement as it might appear when embedded in a COBOL source program:
EXEC SQL DELETE FROM items WHERE order_num = :o-num END-EXEC.
The rst and last lines mark off embedded SQL from the normal COBOL statements. Between them you see an ordinary DELETE statement, as described in Chapter 4, Modifying Data. When this part of the COBOL program is executed, a row of the items table is deleted; multiple rows can also be deleted. The statement contains one new feature. It compares the order_num column to an item written as :o-num, which is the name of a host variable. Each SQL API product provides a means of delimiting the names of host variables when they appear in the context of an SQL statement. In COBOL, host variable names are designated with an initial colon. The example statement asks the database server to delete rows in which the order number equals the current contents of the host variable named :o-num. This is a numeric variable that has been declared and assigned a value earlier in the program. The same DELETE statement embedded in a FORTRAN program looks like the following example:
EXEC SQL DELETE FROM items WHERE order_num = :onum
The same statement embedded in an Ada program looks like the following example:
EXEC SQL DELETE FROM items WHERE order_num = $onum;
In INFORMIX-ESQL/Ada, a host variable is indicated by a leading dollar sign, and statements end with a semicolon. In INFORMIX-ESQL/C a host variable can be introduced with either a dollar sign ($) or a colon (:). The colon (:) is the ANSI-compatible format. The corresponding DELETE statement is written in INFORMIX-ESQL/C as shown in the following example:
EXEC SQL delete FROM items WHERE order_num = :onum;
Calling the Database Server
In INFORMIX-ESQL/C, an SQL statement can be introduced with either a leading dollar sign ($) or the words EXEC SQL. These differences of syntax are trivial; the essential points in all languages (an SQL API, NewEra, INFORMIX-4GL, or SPL) are described in the following list:
s
You can embed SQL statements in a source program as if they were executable statements of the host language. You can use program variables in SQL expressions the way literal values are used.
If you have programming experience, you can immediately see the possibilities. In the example, the order number to be deleted is passed in the variable onum. That value comes from any source that a program can use: It can be read from a le, the program can prompt a user to enter it, or it can be read from the database. The DELETE statement itself can be part of a subroutine (in which case onum can be a parameter of the subroutine); the subroutine can be called once or repetitively. In short, when you embed SQL statements in a program, you can apply all the power of the host language to them. You can hide the SQL under a multitude of interfaces, and you can embellish its functions in a multitude of ways.
Calling the Database Server

Executing an SQL statement is essentially calling the database server as a subroutine. Information must pass from the program to the database server and information must be returned. Some of this communication is done through host variables. You can think of the host variables named in an SQL statement as the parameters of the procedure call to the database server. In the preceding example, a host variable acts as a parameter of the WHERE clause. Also, as described in Retrieving Multiple Rows on page 5-21, host variables receive data that is returned by the database server.
5-8
The SQL Communications Area

The database server always returns a result code, and possibly other information about the effect of an operation, in a data structure known as the SQL Communications Area (SQLCA). If the database server executes an SQL statement in a stored procedure, the SQLCA of the calling application contains the values triggered by the SQL statement in the procedure. The principal elds of the SQLCA are listed in Figure 5-4 on page 5-10 and Figure 5-5 on page 5-11. The syntax you use to describe a data structure such as the SQLCA as well as the syntax you use to refer to a eld in it, differs among programming languages. See your NewEra, INFORMIX-4GL, or SQL API manual for details. You can also use the SQLSTATE variable of the GET DIAGNOSTICS statement to detect, handle, and diagnose errors. See The SQLSTATE Value on page 5-14.
Figure 5-4 The uses of SQLCODE, SQLERRD, and SQLERRP

integer
SQLCODE
0 100 negative array of 6 integers Success. No more data/not found. Error code.
SQLERRD
rst Following successful PREPARE statement for a SELECT, UPDATE, INSERT, or DELETE statement, or after a select cursor is opened, this eld contains the estimated number of affected rows. It is not used in INFORMIX-ESQL/Ada. When SQLCODE contains an error code, this eld contains either zero or an additional error code, called the ISAM error code, that explains the cause of the main error. After a failed CONNECT or DATABASE statement, this eld contains the ISAM, operating system, or network-specic protocol error code. If an application connects to an INFORMIX-Gateway with DRDA, this eld contains the application server error code. In this case, sqlca.sqlcode is -29000. Following a successful insert operation of a single row, this eld contains the value of a generated serial number for that row. third Following a successful multirow insert, update, or delete operation, this eld contains the number of processed rows. Following a multirow insert, update, or delete operation that ends with an error, this eld contains the number of rows successfully processed before the error was detected. fourth Following successful PREPARE statement for a SELECT, UPDATE, INSERT, or DELETE statement, or after a select cursor has been opened, this eld contains the estimated weighted sum of disk accesses and total rows processed. It is not used in INFORMIX-ESQL/Ada. Following a syntax error in a PREPARE, EXECUTE IMMEDIATE, DECLARE, or static SQL statement, this eld contains the offset in the statement text where the error was detected. Following a successful fetch of a selected row or a successful insert, update, or delete operation, this eld contains the rowid (physical address) of the last row processed.
second
fth
sixth character (8)
SQLERRP
Internal use only.
5-10
Figure 5-5 The uses of SQLWARN and SQLERRM

array of 8 characters
SQLWARN
When Opening or Connecting to a Database: Set to W when any eld is set to W. If this eld is blank, the others need not be checked. Set to W when the database now open uses a transaction log. Set to W when the database now open is ANSI-compliant. Set to W when the database server is INFORMIX-OnLine Dynamic Server. Set to W when the database server stores the FLOAT data type in DECIMAL FORM (DONE WHEN THE HOST SYSTEM LACKS SUPPORT FOR FLOAT TYPES). Not used. Set to W when the application is connected to an INFORMIX-OnLine Dynamic Server database server, which is a secondary server in a data replication pair (that is, the database server is available only for read operations). Not used.
rst second third fourth fth sixth seventh
eighth
All Other Operations: rst second third fourth fth sixth seventh eighth character (71) Set to W when any other eld is set to W. Set to W when a column value is truncated as it is fetched into a host variable. Set to W when an aggregate function encounters a null value. On a SELECT or on opening a cursor, set to W when the number of items in the select list is not the same as the number of host variables given in the INTO clause to receive them. Set to W if a prepared statement contains a DELETE or an UPDATE without a WHERE clause. Set to W following execution of a statement that does not use ANSI-standard SQL syntax (provided that the DBANSIWARN environment variable is set). Set to W when a data fragment (a dbspace) is skipped during query processing (when INFORMIX-OnLine Dynamic Server DATASKIP feature is on). Not used.
SQLERRM
Contains the variable, such as table name, that is placed in the error message. For some networked applications, contains an error message generated by networking software. Programming with SQL 5-11
The SQLCODE Field
In particular, the subscript by which you name one element of the SQLERRD and SQLAWARN arrays differs: Array elements are numbered starting with zero in INFORMIX-ESQL/C, but starting with one in the other languages. In this discussion, the elds are named using specic words such as third, and you must translate into the syntax of your programming language.
The SQLCODE Field

The SQLCODE eld is the primary return code of the database server. After every SQL statement, SQLCODE is set to an integer value as shown in Figure 5-4 on page 5-10. When that value is zero, the statement is performed without error. In particular, when a statement is supposed to return data into a host variable, a code of zero means that the data has been returned and can be used. Any nonzero code means the opposite: No useful data was returned to host variables. In INFORMIX-4GL and NewEra, SQLCODE is also accessible under the name STATUS. NewEra also supports access to SQLCODE through ODBC libraries.
End of Data
The database server sets SQLCODE to 100 when the statement is performed correctly but no rows are found. Two situations exist where this can occur. The rst situation involves a query that uses a cursor. (Queries using cursors are described under Retrieving Multiple Rows on page 5-21.) In these queries the FETCH statement retrieves each value from the active set into memory. After the last row is retrieved, a subsequent FETCH statement cannot return any data. When this occurs the database server sets SQLCODE to 100, which says end of data-no rows found. The second situation involves a query that does not use a cursor. In this case, the database server sets SQLCODE to 100 when no rows satisfy the query condition. In ANSI-compliant databases, SELECT, DELETE, UPDATE, and INSERT statements all set SQLCODE to 100 if no rows are returned. In databases that are not ANSI-compliant, only a SELECT statement that returns no rows causes SQLCODE to be set to 100.
5-12
The SQLERRD Array Negative Codes

When something unexpected goes wrong during a statement, the database server returns a negative number in SQLCODE to explain the problem. The meanings of these codes are documented in the Informix Error Messages manual and in the on-line error message le.
The SQLERRD Array

Some error codes that can be reported in SQLCODE reect general problems, and the database server can set a more detailed code in the second eld of SQLERRD. This second code (referred to as the ISAM error) reveals the lowlevel error encountered by the database server I/O routines or by the underlying operating system. The integers in the array named SQLERRD are set to different values following different statements. The rst and fourth elements of the array are used only in INFORMIX-4GL, INFORMIX-ESQL/C, INFORMIX-ESQL/COBOL, and NewEra (Informix CCL only). The elds are used as shown in Figure 5-4 on page 5-10. These additional details can be very useful. For example, you can use the value in the third eld to report how many rows were deleted or updated. When your program prepares an SQL statement entered by the user and an error is found, the value in the fth eld enables you to display the exact point of error to the user. (DB-Access and INFORMIX-SQL use this feature to position the cursor when you ask to modify a statement after an error.)
The SQLWARN Array

The eight character elds in the SQLWARN array are set to either a blank or a W to indicate a variety of special conditions. Their meanings depend on the statement just executed. A set of warning ags appear when a database opens, that is, following a CONNECT, DATABASE or CREATE DATABASE statement. These ags tell you some characteristics of the database as a whole.
The SQLSTATE Value
A second set of ags appear following any other statement. These ags reect unusual events that occur during the statement, which are usually not serious enough to be reected by SQLCODE.
Important: NewEra and INFORMIX-4GL call this array SQLWARN.

Both sets of SQLWARN values are summarized in Figure 5-5 on page 5-11.
The SQLSTATE Value

Certain Informix products, such as INFORMIX-ESQL/COBOL and INFORMIX-ESQL/C, support the SQLSTATE value in compliance with X/Open and ANSI SQL standards. The GET DIAGNOSTICS statement reads the SQLSTATE value in order to diagnose errors after you run an SQL statement. The database server returns a result code in a ve-character string that is stored in a variable called SQLSTATE. The SQLSTATE error code, or value, tells you the following information about the most recently executed SQL statement:
s s s s
If the statement was successful If the statement was successful but generated warnings If the statement was successful but generated no data If the statement failed
For more information on GET DIAGNOSTICS, the SQLSTATE variable, and the meanings of the SQLSTATE return codes, see GET DIAGNOSTICS in Chapter 1 of the Informix Guide to SQL: Syntax. If your Informix product supports GET DIAGNOSTICS and SQLSTATE, Informix recommends that you use them as the primary structure to detect, handle, and diagnose errors. Using SQLSTATE allows you to detect multiple errors and it is ANSI-compliant.
Retrieving Single Rows

You can use embedded SELECT statements to retrieve single rows from the database into host variables. When a SELECT statement returns more than one row of data, however, a program must use a more complicated method to fetch the rows one at a time. Multiple-row select operations are discussed in Retrieving Multiple Rows on page 5-21.
Retrieving Single Rows
To retrieve a single row of data, simply embed a SELECT statement in your program. The following example shows how it can be written using INFORMIX-ESQL/C:
EXEC SQL select avg (total_price) into :avg_price from items where order_num in (select order_num from orders where order_date < date('6/1/94') );
The INTO clause is the only detail that distinguishes this statement from any example in Chapter 2, Composing Simple SELECT Statements, or Chapter 3, Composing Advanced SELECT Statements. This clause species the host variables that are to receive the data that is produced. When the program executes an embedded SELECT statement, the database server performs the query. The example statement selects an aggregate value, so that it produces exactly one row of data. The row has only a single column, and its value is deposited in the host variable named avg_price. Subsequent lines of the program can use that variable. You can use statements of this kind to retrieve single rows of data into host variables. The single row can have as many columns as desired. In the following INFORMIX-4GL example, host variables are used in two ways, as receivers of data and in the WHERE clause:
DEFINE cfname, clname, ccompany CHAR(20) DEFINE cnumbr INTEGER LET cnumbr = 104 SELECT fname, lname, company INTO cfname, clname, ccompany FROM customer WHERE customer_num = cnumbr
Because the customer_num column has a unique index (implemented through a constraint), this query returns only one row. If a query produces more than one row of data, the database server cannot return any data. It returns an error code instead. You should list as many host variables in the INTO clause as there are items in the select list. If, by accident, these lists are of different lengths, the database server returns as many values as it can and sets the warning ag in the fourth eld of SQLWARN.
Data Type Conversion
Data Type Conversion

The following example retrieves the average of a DECIMAL column, which is itself a DECIMAL value. However, the host variable into which it is placed is not required to have that data type.
EXEC SQL select avg (total_price) into :avg_price from items;
The declaration of the receiving variable avg_price in the previous example of ESQL/C code is not shown. It could be any one of the following denitions:
int avg_price; double avg_price; char avg_price[16]; dec_t avg_price; /* typedef of decimal number structure */
The data type of each host variable used in a statement is noted and passed to the database server along with the statement. The database server does its best to convert column data into the form used by the receiving variables. Almost any conversion is allowed, although some conversions cause a loss of precision. The results of the preceding example differ, depending on the data type of the receiving host variable, as described in the following list:
FLOAT
The database server converts the decimal result to FLOAT, possibly truncating some fractional digits. If the magnitude of a decimal exceeds the maximum magnitude of the FLOAT format, an error is returned.
INTEGER
The database server converts the result to integer, truncating fractional digits if necessary. If the integer part of the converted number does not t the receiving variable, an error occurs.
CHARACTER
The database server converts the decimal value to a character string. If the string is too long for the receiving variable, it is truncated. The second eld of SQLWARN is set to W and the value in the SQLSTATE variable is 01004.
5-16
Dealing with Null Data
Dealing with Null Data

What if the program retrieves a null value? Null values can be stored in the database, but the data types supported by programming languages do not recognize a null state. A program must have some way of recognizing a null item to avoid processing it as data. Indicator variables meet this need in SQL APIs. An indicator variable is an additional variable that is associated with a host variable that might receive a null item. When the database server puts data in the main variable, it also puts a special value in the indicator variable to show whether the data is null. In the following INFORMIX-ESQL/C example, a single row is selected and a single value is retrieved into the host variable op_date:
EXEC SQL select paid_date into :op_date:op_d_ind from orders where order_num = $the_order; if (op_d_ind < 0) /* data was null */ rstrdate ('01/01/1900', :op_date);
Because the value might be null, an indicator variable named op_d_ind is associated with the host variable. (It must be declared as a short integer elsewhere in the program.) Following execution of the SELECT statement, the program tests the indicator variable for a negative value. A negative number (usually -1) means that the value retrieved into the main variable is null. If that is the case, this program uses an ESQL/C library function to assign a default value to the host variable. (The function rstrdate is part of the INFORMIX-ESQL/C product.) The syntax you use to associate an indicator variable differs with the language you are using, but the principle is the same in all. However, indicator variables are not used explicitly in INFORMIX-4GL, NewEra, or in SPL because in those languages, null values are supported for variables. In 4GL, the preceding example is written as shown in the following example:
SELECT paid_date INTO op_date FROM orders WHERE order_num = the_order IF op_date IS NULL THEN LET op_date = date ('01/01/1900') END IF
Dealing with Errors
Dealing with Errors

Although the database server handles conversion between data types automatically, several things still can go wrong with a SELECT statement. In SQL programming, as in any kind of programming, you must anticipate errors and provide for them at every point.
End of Data
One common event is that no rows satisfy a query. This is signalled by an SQLSTATE code of 02000 and by a code of 100 in SQLCODE following a SELECT statement. This code indicates an error or a normal event, depending entirely on your application. If you are sure that there ought to be a row or rowsfor example, if you are reading a row using a key value that you just read from a row of another tablethen the end-of-data code represents a serious failure in the logic of the program. On the other hand, if you select a row based on a key supplied by a user or some other source that is less reliable than a program, a lack of data can be a normal event.
End of Data with Databases that Are Not ANSI-Compliant

If your database is not ANSI-compliant, the end-of-data return code, 100, is set in SQLCODE only following SELECT statements. In addition, the SQLSTATE value is set to 02000. (Other statements, such as INSERT, UPDATE, and DELETE, set the third element of SQLERRD to show how many rows they affected; this topic is covered in Chapter 6, Modifying Data Through SQL Programs.)
Serious Errors
Errors that set SQLCODE to a negative value or SQLSTATE to a value beginning with anything other than 00, 01, or 02 are usually serious. Programs that you have developed and are in production should rarely report these errors. Nevertheless, it is difcult to anticipate every problematic situation, so your program must be able to deal with them. For example, a query can return error -206, which means table name is not in the database. This happens if someone dropped the table since the program was written or if, through some error of logic or mistake in input, the program opened the wrong database.
Dealing with Errors Interpreting End of Data with Aggregate Functions

A SELECT statement that uses an aggregate function such as SUM, MIN, or AVG always succeeds in returning at least one row of data. This is true even when no rows satisfy the WHERE clause; an aggregate value based on an empty set of rows is null, but it exists nonetheless. However, an aggregate value is also null if it is based on one or more rows that all contain null values. If you must be able to detect the difference between an aggregate value based on no rows and one based on some rows that are all null, you must include a COUNT function in the statement and an indicator variable on the aggregate value. You can then work out the following cases:
Count Value 0 >0 >0 Indicator -1 -1 0 Case zero rows selected some rows selected; all were null some non-null rows selected
Using Default Values

You can handle these inevitable errors in many ways. In some applications, more lines of code to handle errors are used than for normal situations. In the examples in this section, however, one of the simplest methods, the default value, should work, as shown in the following example:
avg_price = 0; /* set default for errors */ EXEC SQL select avg (total_price) into :avg_price:null_flag from items; if (null_flag < 0) /* probably no rows */ avg_price = 0; /* set default for 0 rows */
Dealing with Errors
The previous example deals with the following considerations:

s
If the query selects some non-null rows, the correct value is returned and used. This is the expected and most frequent result. If the query selects no rows, or in the much less likely event that it selects only rows that have null values in the total_price column (a column that should never be null), the indicator variable is set and the default value is assigned. If any serious error occurs, the host variable is left unchanged; it contains the default value initially set. At this point in the program, the programmer sees no need to trap such errors and report them.
The following example is an expansion of an earlier INFORMIX-4GL example that displays default values if it cannot nd the company that the user requests:
DEFINE cfname, clname, ccompany CHAR(20) DEFINE cnumbr INTEGER PROMPT 'Enter the customer number: ' FOR cnumbr LET cfname = 'unknown' LET clname = 'person' LET ccompany = 'noplace' SELECT fname, lname, company INTO cfname, clname, ccompany WHERE customer_num = cnumbr DISPLAY cfname,' ', clname,' at ', ccompany
This query does not use aggregates, so if no row matches the user-specied customer number, SQLCODE is set to 100 and SQLSTATE is 02000 and the host variables remain unchanged.
5-20
Retrieving Multiple Rows
Retrieving Multiple Rows

When any chance exists that a query could return more than one row, the program must execute the query differently. Multirow queries are handled in two stages. First, the program starts the query. (No data is returned immediately.) Then, the program requests the rows of data one at a time. These operations are performed using a special data object called a cursor. A cursor is a data structure that represents the current state of a query. The following list is the general sequence of program operations:
1. 2. 3. 4. 5.
The program declares the cursor and its associated SELECT statement, which merely allocates storage to hold the cursor. The program opens the cursor, which starts the execution of the associated SELECT statement and detects any errors in it. The program fetches a row of data into host variables and processes it. The program closes the cursor after the last row is fetched. When the cursor is no longer needed, the program frees the cursor to deallocate the resources it uses.
These operations are performed with SQL statements named DECLARE, OPEN, FETCH, CLOSE, and FREE.
Declaring a Cursor
You declare a cursor using the DECLARE statement. This statement gives the cursor a name, species its use, and associates it with a statement. The following example is written in INFORMIX-4GL:
DECLARE the_item CURSOR FOR SELECT order_num, item_num, stock_num INTO o_num, i_num, s_num FROM items
The declaration gives the cursor a name (the_item in this case) and associates it with a SELECT statement. (Chapter 6, Modifying Data Through SQL Programs, discusses how a cursor also can be associated with an INSERT statement.)
Opening a Cursor
The SELECT statement in this example contains an INTO clause. That is one of two ways in which you can specify the variables that receive data. The other way, using the FETCH statement, is discussed in Locating the INTO Clause on page 5-24. The DECLARE statement is not an active statement; it merely establishes the features of the cursor and allocates storage for it. You can use the cursor declared in the preceding example to read once through the items table. Cursors can be declared to read backward and forward (see Cursor Input Modes on page 5-24). This cursor, because it lacks a FOR UPDATE clause, probably is used only to read data, not to modify it. (The use of cursors to modify data is covered in Chapter 6, Modifying Data Through SQL Programs.)
Opening a Cursor
The program opens the cursor when it is ready to use it. The OPEN statement activates the cursor. It passes the associated SELECT statement to the database server, which begins the search for matching rows. The database server processes the query to the point of locating or constructing the rst row of output. It does not actually return that row of data, but it does set a return code in SQLSTATE for SQL APIs and SQLCODE for INFORMIX-4GL and SQL APIs. The following example shows the OPEN statement in INFORMIX-4GL:
OPEN the_item
Because this is the rst time that the database server has seen the query, it is the time when many errors are detected. After opening the cursor, the program should test SQLSTATE or SQLCODE. If the SQLSTATE value is greater than 02000 or the SQLCODE contains a negative number, the cursor is not usable. There may be an error in the SELECT statement, or some other problem may be preventing the database server from executing the statement. If SQLSTATE is equal to 00000 or SQLCODE contains a zero, the SELECT statement is syntactically valid, and the cursor is ready for use. At this point, however, the program does not know if the cursor can produce any rows.
5-22
Fetching Rows
Fetching Rows
The program uses the FETCH statement to retrieve each row of output. This statement names a cursor and can also name the host variables to receive the data. The following example shows the completed INFORMIX-4GL code:
DECLARE the_item CURSOR FOR SELECT order_num, item_num, stock_num INTO o_num, i_num, s_num FROM items OPEN the_item WHILE SQLCA.SQLCODE = 0 FETCH the_item IF SQLCA.SQLCODE = 0 THEN DISPLAY o_num, i_num, s_num END IF END WHILE
Detecting End of Data

In the previous example, the WHILE condition prevents execution of the loop in case the OPEN statement returns an error. The same condition terminates the loop when SQLCODE is set to 100 to signal the end of data. However, the loop contains a test of SQLCODE. This test is necessary because, if the SELECT statement is valid yet nds no matching rows, the OPEN statement returns a zero but the rst fetch returns 100, end of data, and no data. The following example shows another way to write the same loop:
DECLARE the_item CURSOR FOR SELECT order_num, item_num, stock_num INTO o_num, i_num, s_num FROM items OPEN the_item IF SQLCA.SQLCODE = 0 THEN FETCH the_item -- fetch first row END IF WHILE SQLCA.SQLCODE = 0 DISPLAY o_num, i_num, s_num FETCH the_item END WHILE
In this version, the case of zero returned rows is handled early, so no second test of SQLCA.SQLCODE exists within the loop. These versions have no measurable difference in performance because the time cost of a test of SQLCA.SQLCODE is a tiny fraction of the cost of a fetch.
Cursor Input Modes Locating the INTO Clause

The INTO clause names the host variables that are to receive the data returned by the database server. It must appear in either the SELECT or the FETCH statement but not both. The following example is reworked to specify host variables in the FETCH statement:
DECLARE the_item CURSOR FOR SELECT order_num, item_num, stock_num FROM items OPEN the_item WHILE status = 0 FETCH the_item INTO o_num, i_num, s_num IF status = 0 THEN DISPLAY o_num, i_num, s_num END IF END WHILE
The second form has the advantage that different rows can be fetched into different variables. For example, you can use this form to fetch successive rows into successive elements of an array.
Cursor Input Modes

For purposes of input, a cursor operates in one of two modes, sequential or scrolling. A sequential cursor can fetch only the next row in sequence so it can read through a table only once each time it is opened. A scroll cursor can fetch the next row or any prior row, so it can read rows multiple times. The following example shows a sequential cursor declared in INFORMIX-ESQL/C:
EXEC SQL declare pcurs cursor for select customer_num, lname, city from customer;
After it is opened, the cursor can be used only with a sequential fetch that retrieves the next row of data, as shown in the following example:
EXEC SQL fetch p_curs into:cnum, :clname, :ccity;
Each sequential fetch returns a new row. A scroll cursor is declared with the keyword SCROLL, as shown in the following example from INFORMIX-ESQL/FORTRAN:
EXEC SQL DECLARE s_curs SCROLL CURSOR FOR + SELECT order_num, order_date FROM orders + WHERE customer_num > 104
5-24
The Active Set of a Cursor
A scroll cursor can be used with a variety of fetch options. The ABSOLUTE option species the rank number of the row to fetch.
EXEC SQL FETCH ABSOLUTE :numrow s_curs + INTO :nordr, :nodat
This statement fetches the row whose position is given in the host variable numrow. It is also possible to fetch the current row again or to fetch the rst row and then scan through the entire list again. However, these features are obtained at a price, as described in the next section.

Once a cursor is opened, it stands for some selection of rows. The set of all rows that the query produces is called the active set of the cursor. It is easy to think of the active set as a well-dened collection of rows and to think of the cursor as pointing to one row of the collection. This situation is true as long as no other programs are modifying the same data concurrently.
Creating the Active Set

When a cursor is opened, the database server does whatever is necessary to locate the rst row of selected data. Depending on how the query is phrased, this can be very easy to do, or it can require a great deal of work and time. Consider the following declaration of a cursor:
DECLARE easy CURSOR FOR SELECT fname, lname FROM customer WHERE state = 'NJ'
Because this cursor queries only a single table in a simple way, the database server can very quickly discover whether any rows satisfy the query and nd the rst one. The rst row is the only row it nds at this time. The rest of the rows in the active set remain unknown. As a contrast, consider the following declaration of a cursor:
DECLARE hard CURSOR FOR SELECT C.customer_num, O.order_num, sum (items.total_price) FROM customer C, orders O, items I WHERE C.customer_num = O.customer_num AND O.order_num = I.order_num AND O.paid_date is null GROUP BY C.customer_num, O.order_num
The active set of this cursor is generated by joining three tables and grouping the output rows. The optimizer might be able to use indexes to produce the rows in the correct order, but in general the use of ORDER BY or GROUP BY clauses requires the database server to generate all the rows, copy them to a temporary table, and sort the table, before it can know which row to present rst. In cases where the active set is entirely generated and saved in a temporary table, the database server can take quite some time to open the cursor. Afterward, it can tell the program exactly how many rows the active set contains. This information is not made available, however. One reason is that you can never be sure which method the optimizer uses. If it can avoid sorts and temporary tables, it does; but very small changes in the query, in the sizes of the tables, or in the available indexes can change its methods.
The Active Set for a Sequential Cursor

The database server wants to tie up as few resources as possible in maintaining the active set of a cursor. If it can do so, the database server never retains more than the single row that is fetched next. It can do this for most sequential cursors. On each fetch, it returns the contents of the current row and locates the next one.
The Active Set for a Scroll Cursor

All the rows in the active set for a scroll cursor must be retained until the cursor closes because the database server cannot be sure which row the program will ask for next. Most frequently, the database server implements the active set of a scroll cursor as a temporary table. The database server might not ll this table immediately, however (unless it created a temporary table to process the query). Usually it creates the temporary table when the cursor is opened. Then, the rst time a row is fetched, the database server copies it into the temporary table and returns it to the program. When a row is fetched for a second time, it can be taken from the temporary table. This scheme uses the fewest resources in the event that the program abandons the query before it fetches all the rows. Rows that are never fetched are not created or saved.
5-26
The Active Set of a Cursor The Active Set and Concurrency

When only one program is using a database, the members of the active set cannot change. This is the situation in most personal computers, and it is the easiest situation to think about. But some programs must be designed for use in a multiprogramming system, where two, three, or dozens of different programs can work on the same tables simultaneously. When other programs can update the tables while your cursor is open, the idea of the active set becomes less useful. Your program can see only one row of data at a time, but all other rows in the table can be changing. In the case of a simple query, when the database server holds only one row of the active set, any other row can change. The instant after your program fetches a row, another program can delete the same row or update it so that if it is examined again, it is no longer part of the active set. When the active set, or part of it, is saved in a temporary table, stale data can present a problem. That is, the rows in the actual tables, from which the active-set rows are derived, can change. If they do, some of the active-set rows no longer reect the current table contents. These ideas may seem unsettling at rst, but as long as your program only reads the data, there is no such thing as stale data, or rather, all data is equally stale. No matter when it is taken, the active set is a snapshot of the data as it is at one moment in time. A row is different the next day; it does not matter if it is also different in the next millisecond. To put it another way, no practical difference exists between changes that occur while the program is running and changes that are saved and applied the instant the program terminates. The only time that stale data can cause a problem is when the program intends to use the input data to modify the same database; for example, when a banking application must read an account balance, change it, and write it back. Chapter 6, Modifying Data Through SQL Programs, discusses programs that modify data.
Using a Cursor: A Parts Explosion

When you use a cursor, supplemented by program logic, you can solve problems that plain SQL cannot solve. One of these is the parts-explosion problem, sometimes called Bill of Materials processing. At the heart of this problem is a recursive relationship among objects; one object contains other objects, which contain yet others. The problem is usually stated in terms of a manufacturing inventory. A company makes a variety of parts, for example. Some parts are discrete, but some are assemblages of other parts. These relationships are documented in a single table, which might be called contains.The column contains.parent holds the part numbers of parts that are assemblages. The column contains.child has the part number of a part that is a component of the parent. If part #123400 is an assembly of nine parts, nine rows exist with 123400 in the rst column and other part numbers in the second. Figure 5-6 shows one of the rows which describe part #123400.
Figure 5-6 Parts-explosion problem
CHILD FK NN 432100 765899
CONTAINS PARENT FK NN 123400 432100
5-28
The parts-explosion problem is this: given a part number, produce a list of all parts that are components of that part. A sketch of one solution, as implemented in INFORMIX-4GL, is shown in Figure 5-7.
DEFINE part_list ARRAY[200] OF INTEGER FUNCTION boom (top_part) DEFINE this_part, child_part INTEGER DEFINE next_to_do, next_free SMALLINT DECLARE part_scan CURSOR FOR SELECT child INTO child_part FROM contains WHERE parent = this_part LET next_to_do = 1 LET part_list[next_to_do] = top_part LET next_free = 2 WHILE next_to_do < next_free this_part = part_list[next_to_do] FOREACH part_scan LET part_list[next_free] = child_part LET next_free = next_free + 1 END FOREACH LET next_to_do = next_to_do + 1 END WHILE RETURN next_free - 1 END FUNCTION
Figure 5-7 A breadth-rst algorithm to generate a parts explosion
Technically speaking, each row of the contains table is the head node of a directed acyclic graph, or tree. The function in Figure 5-7 performs a breadthrst search of the tree whose root is the part number passed as its parameter. The function uses a cursor named part_scan to return all the rows with a particular value in the parent column. This is very easy to implement using the INFORMIX-4GL statement FOREACH, which opens a cursor, iterates once for each row in the selection set, and closes the cursor. This is the heart of the parts-explosion problem, but it is not a complete solution. For example, the program in Figure 5-7 does not allow for components that appear at more than one level in the tree. Furthermore, a practical contains table would also have a column count, giving the count of child parts used in each parent. A program that returns a total count of each component part is much more complicated.
Dynamic SQL
The iterative approach described earlier is not the only way to approach the parts-explosion problem. If the number of generations has a xed limit, you can solve the problem with a single SELECT statement using nested, outer self-joins. If there can be up to four generations of parts contained within one top-level part, the following SELECT statement returns all of them:
SELECT a.parent, a.child, b.child, c.child, d.child FROM contains a OUTER (contains b, OUTER (contains c, outer contains d) ) WHERE a.parent = top_part_number AND a.child = b.parent AND b.child = c.parent AND c.child = d.parent
This SELECT statement returns one row for each line of descent rooted in the part given as top_part_number. Null values are returned for levels that do not exist. (Use indicator variables to detect them.) You can extend this solution to more levels by selecting additional nested outer joins of the contains table.You also can revise this solution to return counts of the number of parts at each level.
Dynamic SQL
Although static SQL is extremely useful, it requires that you know the exact content of every SQL statement at the time you write the program. For example, you must state exactly which columns are tested in any WHERE clause and exactly which columns are named in any select list. This is no problem when you write a program to perform a well-dened task. But the database tasks of some programs cannot be perfectly dened in advance. In particular, a program that must respond to an interactive user might need the ability to compose SQL statements in response to what the user enters.
5-30
Preparing a Statement
Dynamic SQL allows a program to form an SQL statement during execution, so that the contents of the statement can be determined by user input. This is done in the following steps:
1. 2. 3.
The program assembles the text of an SQL statement as a character string, which is stored in a program variable. It executes a PREPARE statement, which asks the database server to examine the statement text and prepare it for execution. It uses the EXECUTE statement to execute the prepared statement.
In this way, a program can construct and then use any SQL statement, based on user input of any kind. For example, it can read a le of SQL statements and prepare and execute each one.
DB-Access, the utility that you use to explore SQL interactively, is an INFORMIX-ESQL/C program that constructs, prepares, and executes SQL
statements dynamically. For example, it enables users to specify the columns of a table using simple, interactive menus. When the user is nished, DB-Access builds the necessary CREATE TABLE or ALTER TABLE statement dynamically and prepares and executes it.
In form, a dynamic SQL statement is like any other SQL statement that is written into a program, except that it cannot contain the names of any host variables. This leads to two restrictions. First, if it is a SELECT statement, it cannot include the INTO clause. The INTO clause names host variables into which column data is placed, and host variables are not allowed in a dynamic statement. Second, wherever the name of a host variable normally appears in an expression, a question mark (?) is written as a placeholder. You can prepare a statement in this form for execution with the PREPARE statement. The following example is written in INFORMIX-ESQL/C:
EXEC SQL prepare query_2 from 'select * from orders where customer_num = ? and order_date > ?';
Notice the two question marks in this example; they indicate that when the statement is executed, the values of host variables are used at those two points. You can prepare almost any SQL statement dynamically. The only ones that cannot be prepared are the ones directly concerned with dynamic SQL and cursor management, such as the PREPARE and OPEN statements. After you prepare an UPDATE or DELETE statement, it is a good idea to test the fth eld of SQLWARN to see if you used a WHERE clause (see The SQLWARN Array on page 5-13). The result of preparing a statement is a data structure that represents the statement. This data structure is not the same as the string of characters that produced it. In the PREPARE statement, you give a name to the data structure; it is query_2 in the preceding example. This name is used to execute the prepared SQL statement.
THE PREPARE statement does not limit the character string to one statement. It may contain multiple SQL statements, separated by semicolons. Figure 5-8 shows a fairly complex example in INFORMIX-ESQL/COBOL:
MOVE 'BEGIN WORK; UPDATE account SET balance = balance + ? WHERE acct_number = ?; UPDATE teller SET balance = balance + ? WHERE teller_number = ?; UPDATE branch SET balance = balance + ? WHERE branch_number = ?; INSERT INTO history VALUES(timestamp, values);'
Figure 5-8 Preparing a string containing ve SQL statements
TO BIG-QUERY. EXEC SQL PREPARE BIG-Q FROM :BIG-QUERY END-EXEC.
When this list of statements is executed, host variables must provide values for six place-holding question marks. Although it is more complicated to set up a multistatement list, the performance is often better because fewer exchanges take place between the program and the database server.
5-32
Executing Prepared SQL
Executing Prepared SQL

Once a statement is prepared, it can be executed multiple times. Statements other than SELECT statements, and SELECT statements that return only a single row, are executed with the EXECUTE statement. Figure 5-9 shows how INFORMIX-ESQL/C prepares and executes a multistatement update of a bank account:
EXEC SQL BEGIN DECLARE SECTION; char bigquery[270] = "begin work;"; EXEC SQL END DECLARE SECTION; stcat ("update account set balance = balance + ? where ", bigquery); stcat ("acct_number = ?;', bigquery); stcat ("update teller set balance = balance + ? where ", bigquery); stcat ("teller_number = ?;', bigquery); stcat ("update branch set balance = balance + ? where ", bigquery); stcat ("branch_number = ?;', bigquery); stcat ("insert into history values(timestamp, values);", bigquery); EXEC SQL prepare bigq from :bigquery; EXEC SQL execute bigq using :delta, :acct_number, :delta, :teller_number, :delta, :branch_number; EXEC SQL commit work;
Figure 5-9 Preparing and executing a multistatement operation in ESQL/C
The USING clause of the EXECUTE statement supplies a list of host variables whose values are to take the place of the question marks in the prepared statement. If a SELECT (or an EXECUTE PROCEDURE) returns only one row, you can use the INTO clause of EXECUTE to specify the host variables that receive the values.
Executing Prepared SQL Using Prepared SELECT Statements

A dynamically prepared SELECT statement cannot simply be executed; it might produce more than one row of data, and the database server, not knowing which row to return, produces an error code. Instead, a dynamic SELECT statement is attached to a cursor. Then, the cursor is opened and used in the usual way. The cursor to be used with a prepared statement is declared for that statement name. The following example is written in INFORMIX-4GL:
LET select_2 = 'select order_num, order_date from orders ', 'where customer_num = ? and order_date > ?' PREPARE q_orders FROM select_2 DECLARE cu_orders CURSOR FOR q_orders OPEN cu_orders USING q_c_number, q_o_date FETCH cu_orders INTO f_o_num, f_o_date
The following list identies the stages of processing in the 4GL example:
1. 2.
A character string expressing a SELECT statement is placed in a program variable. It employs two place-holding question marks. The PREPARE statement converts the string into a data structure that can be executed. The data structure is associated with a name, q_orders. A cursor named cu_orders is declared and associated with the name of the prepared statement. When the cursor is opened, the prepared statement is executed. The USING clause in the OPEN statement provides the names of two host variables whose contents are substituted for the question marks in the original statement. The rst row of data is fetched from the open cursor. The INTO clause of the FETCH statement species the host variables that are to receive the fetched column values.
3. 4.
5.
Later, the cursor can be closed and reopened. While the cursor is closed, a different SELECT statement can be prepared under the name q_orders. In this way, a single cursor can be used to fetch from different SELECT statements.
5-34
Dynamic Host Variables
Dynamic Host Variables

In SQL APIs, which support dynamically allocated data objects, it is possible to take dynamic statements one step further. It is possible to dynamically allocate the host variables that receive column data. This makes it possible to take an arbitrary SELECT statement from program input, determine how many values it produces and their data types, and allocate the host variables of the appropriate types to hold them. The key to this ability is the DESCRIBE statement. It takes the name of a prepared SQL statement and returns information about the statement and its contents. It sets SQLCODE to specify the type of statement; that is, the verb with which it begins. If the prepared statement is a SELECT, the DESCRIBE statement also returns information about the selected output data. If the prepared statement is an INSERT, the DESCRIBE statement returns information about the input parameters. The data structure is a predened data structure allocated for this purpose and is known as a system-descriptor area. If you are using INFORMIX-ESQL/C, you can use a system-descriptor area or, as an alternative, an sqlda structure. The data structure that A DESCRIBE statement returns or references for a SELECT statement includes an array of structures. Each structure describes the data that is returned for one item in the select list. The program can examine the array and discover that a row of data includes a decimal value, a character value of a certain length, and an integer. Using this information, the program can allocate memory to hold the retrieved values and put the necessary pointers in the data structure for the database server to use.
Freeing Prepared Statements
Freeing Prepared Statements

A prepared SQL statement occupies space in memory. With some database servers, it can consume space owned by the database server as well as space belonging to the program. This space is released when the program terminates, but in general, you should free this space when you nish with it. You can use the FREE statement to release this space. It takes either the name of a statement or the name of a cursor that was declared for a statement name, and releases the space allocated to the prepared statement. If more than one cursor is dened on the statement, freeing the statement does not free the cursor.
Quick Execution
For simple statements that do not require a cursor or host variables, you can combine the actions of the PREPARE, EXECUTE, and FREE statements into a single operation. The EXECUTE IMMEDIATE statement, shown in the following example, takes a character string, prepares it, executes it, and frees the storage in one operation.
exec sql execute immediate 'drop index my_temp_index';
This makes it easy to write simple SQL operations. However, because no USING clause is allowed, the EXECUTE IMMEDIATE statement cannot be used for SELECT statements.
Embedding Data Denition Statements

Data denition statements, the SQL statements that create databases and modify the denitions of tables, are not usually put into programs. The reason is that they are rarely performeda database is created once, but is queried and updated many times. The creation of a database and its tables is generally done interactively, using DB-Access or INFORMIX-SQL. These tools can also be driven from a le of statements, so that the creation of a database can be done with one operating system command.
5-36
Embedding Grant and Revoke Privileges

One task related to data denition is done repeatedly: the granting and revoking of privileges. The reasons for this are discussed in Chapter 10, Granting and Limiting Access to Your Database. Because privileges must be granted and revoked frequently, and because this might be done by persons who are not skilled in SQL, it can be useful to package the GRANT and REVOKE statements in programs to give them a simpler, more convenient user interface. The GRANT and REVOKE statements are especially good candidates for dynamic SQL. Each statement takes the following parameters:
s s s
A list of one or more privileges A table name The name of a user
You probably need to supply at least some of these values based on program input (from the user, command-line parameters, or a le) but none can be supplied in the form of a host variable. The syntax of these statements does not allow host variables at any point. The only alternative is to assemble the parts of a statement into a character string, and prepare and execute the assembled statement. Program input can be incorporated into the prepared statement as characters.
Figure 5-10 shows a function in INFORMIX-4GL that assembles a GRANT statement from the function parameters, and then prepares and executes it.
FUNCTION table_grant (priv_to_grant, table_name, user_id) DEFINE priv_to_grant char(100), table_name char(20), user_id char(20), grant_stmt char(200) LET grant_stmt =' GRANT ', priv_to_grant, ' ON ', table_name, ' TO ', user_id WHENEVER ERROR CONTINUE PREPARE the_grant FROM grant_stmt IF status = 0 THEN EXECUTE the_grant END IF IF status <> 0 THEN DISPLAY 'Sorry, got error #', status, 'attempting:' DISPLAY ' ',grant_stmt END IF WHENEVER ERROR STOP FREE the_grant END FUNCTION
Figure 5-10 A 4GL function that builds, prepares, and executes a GRANT statement
The opening statement, shown in the following example, denes the name of the function and the names of its three parameters:
FUNCTION table_grant (priv_to_grant, table_name, user_id)
The DEFINE statement, shown in the following example, denes the parameters and one additional variable local to the function. All four are character strings of various lengths.
DEFINE priv_to_grant char(100), table_name char(20), user_id char(20), grant_stmt char(200)
The variable grant_stmt holds the assembled GRANT statement, which is created by concatenating the parameters and some constants. This is shown in the following example:
LET grant_stmt ='GRANT ', priv_to_grant, ' ON ', table_name, ' TO ', user_id
5-38
This assignment statement uses the comma as a list delimiter to concatenate the following six character strings:
s s s s s s
'GRANT'
The parameter specifying the privileges to be granted

'ON'
The parameter specifying the table name

'TO'
The parameter specifying the user.
The result is a complete GRANT statement composed partly of program input. The same feat can be accomplished in other host languages using different syntax, as shown in the following gure:
WHENEVER ERROR CONTINUE PREPARE the_grant FROM grant_stmt
If the database server returns an error code in SQLCODE, the default action of an INFORMIX-4GL program is to terminate. However, errors are quite likely when you prepare an SQL statement composed of user-supplied parts, and program termination is a poor way to diagnose the error. In the preceding code, the WHENEVER statement prevents termination. Then the PREPARE statement passes the assembled statement text to the database server for parsing. If the database server approves the form of the statement, it sets a zero return code. This does not guarantee that the statement is executed properly; it means only that the statement has correct syntax. It might refer to a nonexistent table or contain many other kinds of errors that can be detected only during execution. The following portion of the example in Figure 5-10 checks that the_grant was prepared successfully before executing it.
IF status = 0 THEN EXECUTE the_grant END IF
If the preparation is successful, the next step is to execute the prepared statement. The function in Figure 5-10 on page 5-38 displays an error message if anything goes wrong. As written, it makes no distinction between an error from the PREPARE operation and one from the EXECUTE operation. It does not attempt to interpret the numeric error code, leaving it to the user to interpret.
Summary
Summary
SQL statements can be written into programs as if they were normal
statements of the programming language. Program variables can be used in WHERE clauses, and data from the database can be fetched into them. A preprocessor translates the SQL code into procedure calls and data structures. Statements that do not return data, or queries that return only one row of data, are written like ordinary imperative statements of the language. Queries that can return more than one row are associated with a cursor that represents the current row of data. Through the cursor, the program can fetch each row of data as it is needed. Static SQL statements are written into the text of the program. However, the program can form new SQL statements dynamically, as it runs, and execute them also. In the most advanced cases, the program can obtain information about the number and types of columns that a query returns and dynamically allocate the memory space to hold them.
5-40
Chapter
Modifying Data Through SQL Programs

Using DELETE . . . . . . . . Direct Deletions . . . . . . Errors During Direct Deletions Using Transaction Logging . Coordinated Deletions . . . Deleting with a Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 3 6- 4 6- 4 6- 5 6- 6 6- 7 6- 9 6- 9 6- 9 6- 10 6- 11 6- 12 6- 12 6- 15 6- 15 6- 16 6- 16 6- 16 6- 17 6- 18
Using INSERT . . . . . . . . . . Using an Insert Cursor . . . . . . Declaring an Insert Cursor . . . Inserting with a Cursor. . . . . Status Codes After PUT and FLUSH Rows of Constants. . . . . . . . An Insert Example. . . . . . . .
Using UPDATE . . . . . . . . . . . . Using an Update Cursor . . . . . . . The Purpose of the Keyword UPDATE . Updating Specic Columns . . . . . UPDATE Keyword Not Always Needed . Cleaning up a Table . . . . . . . . . Summary . . . . . . . . . . . . . .
6-2
he preceding chapter introduced the idea of putting SQL statements, especially the SELECT statement, into programs written in other languages. This enables a program to retrieve rows of data from a database. This chapter covers the issues that arise when a program needs to modify the database by deleting, inserting, or updating rows. As in Chapter 5, Programming with SQL, this chapter aims to prepare you for reading the manual for your Informix ESQL, NewEra, or 4GL product. The general use of the INSERT, UPDATE, and DELETE statements is covered in Chapter 4, Modifying Data. This chapter examines their use from within a program. It is quite easy to put the statements in a program, but it can be quite difcult to handle errors and to deal with concurrent modications from multiple programs.
Using DELETE
A program deletes rows from a table by executing a DELETE statement. The DELETE statement can specify rows in the usual way with a WHERE clause, or it can refer to a single row, the last one fetched through a specied cursor. Whenever you delete rows, you must consider whether rows in other tables depend on the deleted rows. This problem of coordinated deletions is covered in Chapter 4, Modifying Data. The problem is the same when deletions are made from within a program.
Modifying Data Through SQL Programs 6-3
Direct Deletions
Direct Deletions
You can embed a DELETE statement in a program. The following example uses INFORMIX-ESQL/C:
EXEC SQL delete from items where order_num = :onum;
You can also prepare and execute a statement of the same form dynamically. In either case, the statement works directly on the database to affect one or more rows. The WHERE clause in the example uses the value of a host variable named onum. Following the operation, results are posted in the SQLSTATE and in SQLCA, as usual. The third element of the SQLERRD array contains the count of rows deleted even if an error occurs. The value in SQLCODE shows the overall success of the operation. If it is not negative, no errors occurred and the third element of SQLERRD is the count of all rows that satised the WHERE clause and were deleted.
Errors During Direct Deletions

When an error occurs, the statement ends prematurely. The values in SQLSTATE and in SQLCODE and the second element of SQLERRD explain its cause, and the count of rows reveals how many rows were deleted. For many errors, that count is zero because they prevented the database server from beginning the operation. For example, if the named table does not exist or if a column tested in the WHERE clause is renamed, no deletions are attempted. However, certain errors can be discovered after the operation begins and some rows are processed. The most common of these errors is a lock conict. The database server must obtain an exclusive lock on a row before it can delete that row. Other programs might be using the rows from the table, preventing the database server from locking a row. Because the issue of locking affects all types of modications, it is discussed Chapter 7, Programming for a Multiuser Environment. Other, rarer types of errors can strike after deletions begin, for example, hardware errors that occur while the database is being updated.
6-4
Direct Deletions Using Transaction Logging

The best way to prepare for any kind of error during a modication is to use transaction logging. In the event of an error, you can tell the database server to put the database back the way it was. The following example is based on the example in Direct Deletions on page 6-4, which is extended to use transactions:
EXEC SQL begin work;/* start the transaction*/ EXEC SQL delete from items where order_num = :onum; del_result = sqlca.sqlcode;/* save two error */ del_isamno = sqlca.sqlerrd[1];/* ...code numbers */ del_rowcnt = sqlca.sqlerrd[2];/* ...and count of rows */ if (del_result < 0)/* some problem, */ EXEC SQL rollback work;/* ...put everything back */ else /* everything worked OK, */ EXEC SQL commit work;/* ...finish transaction */
An important point in this example is that the program saves the important return values in the sqlca structure before it ends the transaction. The reason is that both the ROLLBACK WORK and COMMIT WORK statements, as with all SQL statements, set return codes in the sqlca structure. Executing a ROLLBACK WORK statement after an error wipes out the error code; unless it was saved, it cannot be reported to the user. The advantage of using transactions is that the database is left in a known, predictable state no matter what goes wrong. No question remains about how much of the modication is completed; either all of it is or none of it is.
Direct Deletions Coordinated Deletions

The usefulness of transaction logging is particularly clear when you must modify more than one table. For example, consider the problem of deleting an order from the demonstration database. In the simplest form of the problem, you must delete rows from two tables, orders and items, as shown in the INFORMIX-4GL example in Figure 6-1.
WHENEVER ERROR CONTINUE{do not terminate on error} BEGIN WORK {start transaction} DELETE FROM items WHERE order_num = o_num IF (status >= 0) THEN {no error on first delete} DELETE FROM orders WHERE order_num = o_num END IF IF (status >= 0) THEN {no error on either delete} COMMIT WORK ELSE {problem on some delete} DISPLAY 'Error ', status,' deleting.' ROLLBACK WORK END IF
Figure 6-1 A fragment of 4GL that deletes from two tables
The logic of this program is much the same regardless if transactions are used. If they are not used, the person who sees the error message has a much more difcult set of decisions to make. Depending on when the error occurred, one of the following situations applies:
s
No deletions were performed; all rows with this order number remain in the database. Some, but not all, item rows were deleted; an order record with only some items remains. All item rows were deleted, but the order row remains. All rows were deleted.
s s
In the second and third cases, the database is corrupted to some extent; it contains partial information that can cause some queries to produce wrong answers. You must take careful action to restore consistency to the information. When transactions are used, all these uncertainties are prevented.
6-6
Deleting with a Cursor

You can also write a DELETE statement through a cursor to delete the row that was last fetched. This lets you program deletions based on conditions that cannot be tested in a WHERE clause, as shown in Figure 6-2.
int delDupOrder() { int ord_num; int dup_cnt, ret_code; EXEC SQL declare scan_ord cursor for select order_num, order_date into :ord_num, :ord_date from orders for update; EXEC SQL open scan_ord; if (sqlca.sqlcode != 0) return (sqlca.sqlcode); exec sql begin work; for(;;) { EXEC SQL fetch next scan_ord; if (sqlca.sqlcode != 0) break; dup_cnt = 0; /* default in case of error */ EXEC SQL select count(*) into dup_cnt from orders where order_num = :ord_num; if (dup_cnt > 1) { EXEC SQL delete where current of scan_ord; if (sqlca.sqlcode != 0) break; } } ret_code = sqlca.sqlcode; if (ret_code == 100) /* merely end of data */ EXEC SQL commit work; else /* error on fetch or on delete */ EXEC SQL rollback work; return (ret_code); }
Figure 6-2 An unsafe ESQL/C function that deletes through a cursor
Warning: The design of the ESQL/C function in Figure 6-2 is unsafe. It depends on the current isolation level for correct operation. Depending on isolation level is later in the chapter. Even when it works as intended, its effects depend on the physical order of rows in the table, which is not generally a good idea.
The purpose of the function is to delete rows containing duplicate order numbers. In fact, in the demonstration database, the orders.order_num column has a unique index, so duplicate rows cannot occur in it. However, a similar function can be written for another database; this one uses familiar column names. The function declares scan_ord, a cursor to scan all rows in the orders table. It is declared with the FOR UPDATE clause, which states that the cursor can modify data. If the cursor opens properly, the function begins a transaction and then loops over rows of the table. For each row, it uses an embedded SELECT statement to determine how many rows of the table have the order number of the current row. (This step fails without the correct isolation level, as described in Chapter 7, Programming for a Multiuser Environment.) In the demonstration database, with its unique index on this table, the count returned to dup_cnt is always one. However, if it is greater, the function deletes the current row of the table, reducing the count of duplicates by one. Clean-up functions of this sort are sometimes needed, but they generally need more sophisticated design. This one deletes all duplicate rows except the last one delivered by the database server. That ordering has nothing to do with the contents of the rows or their meanings. You can improve the function in Figure 6-2 on page 6-7 by adding, perhaps, an ORDER BY clause to the cursor declaration. However, you cannot use ORDER BY and FOR UPDATE together. A better approach is sketched in An Insert Example on page 6-12.
6-8
Using INSERT
Using INSERT
You can embed the INSERT statement in programs. Its form and use in a program are the same as described in Chapter 4, Modifying Data, with the additional feature that you can use host variables in expressions, both in the VALUES and WHERE clauses. Moreover, a program has the additional ability to insert rows using a cursor.
Using an Insert Cursor

The DECLARE CURSOR statement has many variations. Most are used to create cursors for different kinds of scans over data, but one variation creates a special kind of cursor called an insert cursor. You use an insert cursor with the PUT and FLUSH statements to efciently insert rows into a table in bulk.
Declaring an Insert Cursor

You create an insert cursor by declaring a cursor to be for an INSERT statement instead of a SELECT statement. You cannot use such a cursor to fetch rows of data; you can use it only to insert them. An example of the declaration of an insert cursor is shown in Figure 6-3.
DEFINE the_company LIKE customer.company, the_fname LIKE customer.fname, the_lname LIKE customer.lname DECLARE new_custs CURSOR FOR INSERT INTO customer (company, fname, lname) VALUES (the_company, the_fname, the_lname)
Figure 6-3 A 4GL fragment that declares an insert cursor
When you open an insert cursor, a buffer is created in memory to hold a block of rows. The buffer receives rows of data as the program produces them; then they are passed to the database server in a block when the buffer is full. This reduces the amount of communication between the program and the database server, and it lets the database server insert the rows with less difculty. As a result, the insertions go faster.
The minimum size of the insert buffer is set for any implementation of embedded SQL; you have no control over it (it is typically 1 or 2 kilobytes). The buffer is always made large enough to hold at least two rows of inserted values. It is large enough to hold more than two rows when the rows are shorter than the minimum buffer size.
Inserting with a Cursor

The code in Figure 6-3 on page 6-9 prepares an insert cursor for use. The continuation, shown in Figure 6-4, shows how the cursor can be used. For simplicity, this example assumes that a function named next_cust returns either information about a new customer or null data to signal the end of input.
WHENEVER ERROR CONTINUE{do not terminate on error} BEGIN WORK OPEN new_custs WHILE status = 0 CALL next_cust() RETURNING the_company, the_fname, the_lname IF the_company IS NULL THEN EXIT WHILE END IF PUT new_custs END WHILE IF status = 0 THEN {no problem in a PUT} FLUSH new_custs {write any last rows} END IF IF status = 0 THEN {no problem writing} COMMIT WORK {..make it permanent} ELSE ROLLBACK WORK {retract any changes} END IF
Figure 6-4 Continuing , the 4GL code that uses the insert cursor
The code in Figure 6-4 calls next_cust repeatedly. When it returns non-null data, the PUT statement sends the returned data to the row buffer. When the buffer lls, the rows it contains are automatically sent to the database server. The loop normally ends when next_cust has no more data to return. Then the FLUSH statement writes any rows that remain in the buffer, after which the transaction terminates.
6-10
Examine the INSERT statement in Figure 6-3 on page 6-9 once more. The statement by itself, not part of a cursor denition, inserts a single row into the customer table. In fact, the whole apparatus of the insert cursor can be dropped from the example code, and the INSERT statement can be written into Figure 6-4 on page 6-10 where the PUT statement now stands. The difference is that an insert cursor causes a program to run somewhat faster.
Status Codes After PUT and FLUSH

When a program executes a PUT statement, the program should test whether the row is placed in the buffer successfully. If the new row ts in the buffer, the only action of PUT is to copy the row to the buffer. No errors can occur in this case. However, if the row does not t, the entire buffer load is passed to the database server for insertion, and an error can occur. The values returned into the SQL Communications Area ( SQLCA) give the program the information it needs to sort out each case. SQLCODE and SQLSTATE are set after every PUT statementto zero if no error occurs and to a negative error code if an error occurs. The third element of SQLERRD is set to the number of rows actually inserted into the table: It is set to zero if the new row is merely moved to the buffer; to the count of rows that are in the buffer, if the buffer load is inserted without error; or to the count of rows inserted before an error occurs, if one does occur. Read the code once again to see how SQLCODE is used (see Figure 6-4 on page 6-10). First, if the OPEN statement yields an error, the loop is not executed because the WHILE condition fails, the FLUSH operation is not performed, and the transaction rolls back. Second, if the PUT statement returns an error, the loop ends because of the WHILE condition, the FLUSH operation is not performed, and the transaction rolls back. This can occur only if the loop generates enough rows to ll the buffer at least once; otherwise, the PUT statement cannot generate an error. The program might end the loop with rows still in the buffer, possibly without inserting any rows. At this point, the SQL status is zero, and the FLUSH operation occurs. If the FLUSH operation produces an error code, the transaction rolls back. Only when all inserts are successfully performed is the transaction committed.
Rows of Constants
Rows of Constants
The insert cursor mechanism supports one special case where high performance is easy to obtain. This is the case in which all the values listed in the INSERT statement are constantsno expressions and no host variables, just literal numbers and strings of characters. No matter how many times such an INSERT operation occurs, the rows it produces are identical. In that case, there is no point in copying, buffering, and transmitting each identical row. Instead, for this kind of INSERT operation, the PUT statement does nothing except to increment a counter. When a FLUSH operation is nally performed, a single copy of the row, and the count of inserts, is passed to the database server. The database server creates and inserts that many rows in one operation. It is not common to insert a quantity of identical rows. You can do it when you rst establish a database, to populate a large table with null data.
An Insert Example
Deleting with a Cursor on page 6-7 contains an example of the DELETE statement whose purpose is to look for and delete duplicate rows of a table. A better way to do the same thing is to select the desired rows instead of deleting the undesired ones. The code in Figure 6-5 on page 6-13 shows one way to do this. The example is written in INFORMIX-4GL to take advantage of some features that make SQL programming easy.
6-12
An Insert Example
BEGIN WORK INSERT INTO new_orders SELECT * FROM ORDERS main WHERE 1 = (SELECT COUNT(*) FROM ORDERS minor WHERE main.order_num = minor.order_num) COMMIT WORK DEFINE ord_row RECORD LIKE orders, last_ord LIKE orders.order_num DECLARE dup_row CURSOR FOR SELECT * FROM ORDERS main INTO ord_row.* WHERE 1 < (SELECT COUNT(*) FROM ORDERS minor WHERE main.order_num = minor.order_num) ORDER BY order_date DECLARE ins_row CURSOR FOR INSERT INTO new_orders VALUES (ord_row.*) BEGIN WORK OPEN ins_row LET last_ord = -1 FOREACH dup_row IF ord_row.order_num <> last_ord THEN PUT ins_row LET last_ord = ord_row.order_num END IF END FOREACH CLOSE ins_row COMMIT WORK
Figure 6-5 A 4GL program that re-creates a table without duplicates
This example begins with an ordinary INSERT statement, which nds all the nonduplicated rows of the table and inserts them into another table, presumably created before the program started. That leaves only the duplicate rows. (Remember, in the demonstration database the orders table has a unique index and cannot have duplicate rows. This example deals with some other database.) In NewEra and INFORMIX-4GL, you can dene a data structure like a table; the structure is automatically given one element for each column in the table. The ord_row structure is a buffer to hold one row of the table. The code in Figure 6-5 then declares two cursors. The rst, called dup_row, returns the duplicate rows in the table. Because it is for input only, it can use the ORDER BY clause to impose some order on the duplicates other than the physical record order used in Figure 6-2 on page 6-7. In this example, the duplicate rows are ordered by their dates (the oldest one remains), but you can use any other order based on the data.
An Insert Example
The second cursor is an insert cursor. It is written to take advantage of the asterisk (*) notation of INFORMIX-4GL; you can supply values for all columns simply by naming a record with an asterisk to indicate all elds. The remainder of the code examines the rows returned through dup_row. It inserts the rst one from each group of duplicates into the new table and disregards the rest. This example uses the simplest kind of error handling. Unless told otherwise, an INFORMIX-4GL program automatically terminates when an error code is set in SQLCODE. In this event, the active transaction rolls back. This program relies on that behavior; it assumes that if it reaches the end, no errors exist and the transaction can be committed. This kind of error handling is acceptable when errors are unlikely, and the program is used by people who do not need to know why the program terminates.
How Many Rows Were Affected?

When your program uses a cursor to select rows, it can test SQLCODE for 100 (or SQLSTATE for 02000), the end-of-data return code. This is set to indicate that no rows, or no more rows, satisfy the query conditions. For databases that are not ANSI-compliant, the end-of-data return code is set in SQLCODE or SQLSTATE only following SELECT statements; it is not used following DELETE, INSERT, or UPDATE statements. For ANSI-compliant databases, SQLCODE is also set to 100 for updates, deletes, and inserts that affect zero rows. A query that nds no data is not a success. However, an UPDATE or DELETE statement that happens to update or delete no rows is still considered a success: It updated or deleted the set of rows that its WHERE clause said it should; however, the set was empty. In the same way, the INSERT statement does not set the end-of-data return code even when the source of the inserted rows is a SELECT statement and it selected no rows. The INSERT statement is a success because it inserted as many rows as it was asked to do (that is, zero). To nd out how many rows are inserted, updated, or deleted, a program can test the third element of SQLERRD. The count of rows is there, regardless of the value (zero or negative) in SQLCODE.
6-14
Using UPDATE
Using UPDATE
You can embed the UPDATE statement in a program in any of the forms described in Chapter 4, Modifying Data, with the additional feature that you can name host variables in expressions, both in the SET and WHERE clauses. Moreover, a program can update the row addressed by a cursor.
Using an Update Cursor

An update cursor permits you to delete or update the current row; that is, the most recently fetched row. The following example (in INFORMIX-ESQL/COBOL) shows the declaration of an update cursor:
EXEC SQL DECLARE names CURSOR FOR SELECT fname, lname, company FROM customer FOR UPDATE END-EXEC.
The program that uses this cursor can fetch rows in the usual way.
EXEC SQL FETCH names INTO :FNAME, :LNAME, :COMPANY END-EXEC.
If the program then decides that the row needs to be changed, it can do so.
IF COMPANY IS EQUAL TO 'SONY' EXEC SQL UPDATE customer SET fname = 'Midori', lname = 'Tokugawa' WHERE CURRENT OF names END-EXEC.
The words CURRENT OF names take the place of the usual test expressions in the WHERE clause. In other respects, the UPDATE statement is the same as usualeven including the specication of the table name, which is implicit in the cursor name but still required.
Using an Update Cursor The Purpose of the Keyword UPDATE

The purpose of the keyword UPDATE in a cursor is to let the database server know that the program can update (or delete) any row that it fetches. The database server places a more demanding lock on rows that are fetched through an update cursor and a less demanding lock when fetching a row for a cursor that is not declared with that keyword. This results in better performance for ordinary cursors and a higher level of concurrent use in a multiprocessing system. (Levels of locks and concurrent use are discussed in Chapter 7, Programming for a Multiuser Environment.)
Updating Specic Columns

The following example has updated specic columns of the preceeding example of an update cursor:
EXEC SQL DECLARE names CURSOR FOR SELECT fname, lname, company, phone INTO :FNAME,:LNAME,:COMPANY,:PHONE FROM customer FOR UPDATE OF fname, lname END-EXEC.
Only the fname and lname columns can be updated through this cursor. A statement such as the following one is rejected as an error:
EXEC SQL UPDATE customer SET company = 'Siemens' WHERE CURRENT OF names END-EXEC.
If the program attempts such an update, an error code is returned and no update occurs. An attempt to delete using WHERE CURRENT OF is also rejected because deletion affects all columns.
UPDATE Keyword Not Always Needed

The ANSI standard for SQL does not provide for the FOR UPDATE clause in a cursor denition. When a program uses an ANSI-compliant database, it can update or delete using any cursor.
6-16
Cleaning up a Table
Cleaning up a Table
A nal, hypothetical example of using an update cursor presents a problem that should never arise with an established database but could arise in the initial design phases of an application. A large table, named target, for example, is created and populated. A character column, datcol, inadvertently acquires some null values. These rows should be deleted. Furthermore, a new column, serials, is added to the table with the ALTER TABLE statement. This column is to have unique integer values installed. Figure 6-6 shows the INFORMIX-ESQL/C code needed to accomplish these things.
EXEC SQL BEGIN DECLARE SECTION; char dcol[80]; short dcolint; int sequence; EXEC SQL END DECLARE SECTION; EXEC SQL DECLARE target_row CURSOR FOR SELECT datcol INTO :dcol:dcolint FROM target FOR UPDATE OF serials; EXEC SQL BEGIN WORK; EXEC SQL OPEN target_row; if (sqlca.sqlcode == 0) EXEC SQL FETCH NEXT target_row; for(sequence = 1; sqlca.sqlcode == 0; ++sequence) { if (dcolint < 0) /* null datcol */ EXEC SQL DELETE WHERE CURRENT OF target_row; else EXEC SQL UPDATE target SET serials = :sequence WHERE CURRENT OF target_row; } if (sqlca.sqlcode >= 0) EXEC SQL COMMIT WORK; else EXEC SQL ROLLBACK WORK;
Figure 6-6 Cleaning up a table using an update cursor
Summary
Summary
A program can execute the INSERT, DELETE, and UPDATE statements as described in Chapter 4, Modifying Data. A program also can scan through a table with a cursor, updating or deleting selected rows. It also can use a cursor to insert rows, with the benet that the rows are buffered and sent to the database server in blocks. In all these activities, you must make sure that the program detects errors and returns the database to a known state when an error occurs. The most important tool for doing this is the transaction. Without transaction logging, it is more difcult to write the program so that it can recover from errors.
6-18
Chapter

Concurrency and Performance . Locking and Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 7-3 7-4 7-4 7-6 7-6 7-7 7-7 7-8 7-9 7-9 7-10
Locking and Performance Concurrency Issues. . .
How Locks Work . . . . . . Kinds of Locks . . . . . . Lock Scope . . . . . . . Database Locks . . . . Table Locks . . . . . . Page, Row, and Key Locks. The Duration of a Lock . . . Locks While Modifying . . .
Setting the Isolation Level . . . . . . . . . . . . . . . . 7-11 Comparing SET TRANSACTION with SET ISOLATION . . . . 7-11 ANSI Read Uncommitted and Informix Dirty Read Isolation . . . 7-12 ANSI Read Committed and Informix Committed Read Isolation. . 7-13 Informix Cursor Stability Isolation . . . . . . . . . . . . 7-13 ANSI Serializable, ANSI Repeatable Read and Informix Repeatable Read Isolation . . . . . . . . . . . . . . . . . . . . 7-15 Controlling Data Modication with Access Modes . Setting the Lock Mode. . . . Waiting for Locks . . . . Not Waiting for Locks . . Waiting a Limited Time . . Handling a Deadlock . . . Handling External Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16 7-17 7-17 7-17 7-18 7-18 7-19
Simple Concurrency
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
7-19 7-20 7-21 7-21 7-22 7-23
Locking with Other Database Servers Isolation While Reading . . . . Locking Updated Rows . . . . Hold Cursors . Summary . . . . . . . . . . . . . . . . . .
7-2
f your database is contained in a single-user workstation and is not connected on a network to other computers, your programs can modify data freely. But in all other cases, you must allow for the possibility that, while your program is modifying data, another program is reading or modifying the same data. This is concurrency: two or more independent uses of the same data at the same time. This chapter addresses concurrency, locking, and isolation levels.
Concurrency and Performance

Concurrency is crucial to good performance in a multiprogramming system. When access to the data is serialized so that only one program at a time can use it, processing slows dramatically.
Locking and Integrity

Unless controls are placed on the use of data, concurrency can lead to a variety of negative effects. Programs can read obsolete data or modications can be lost even though they were apparently completed. The database server prevents errors of this kind by imposing a system of locks. A lock is a claim, or reservation, that a program can place on a piece of data. The database server guarantees that, as long as the data is locked, no other program can modify it. When another program requests the data, the database server either makes the program wait or turns it back with an error.
7-3
Locking and Performance
Locking and Performance

Because a lock serializes access to one piece of data, it reduces concurrency; any other programs that want access to that data must wait. The database server can place a lock on a single row, a disk page (which holds multiple rows), a whole table, or an entire database. The more locks it places and the larger the objects it locks, the more concurrency is reduced. The fewer the locks and the smaller the locked objects, the greater concurrency and performance can be. This section discusses how a program can achieve the following goals:
s s
To place all the locks needed to ensure data integrity To lock the fewest, smallest pieces of data possible consistent with the preceding goal
Concurrency Issues
To understand the hazards of concurrency, you must think in terms of multiple programs, each executing at its own speed. Suppose that your program is fetching rows through the following cursor:
DECLARE sto_curse CURSOR FOR SELECT * FROM stock WHERE manu_code = 'ANZ'
The transfer of each row from the database server to the program takes time. During and between transfers, other programs can perform other database operations. Say that at about the same time your program fetches the rows produced by that query, another users program executes the following update:
UPDATE stock SET unit_price = 1.15 * unit_price WHERE manu_code = 'ANZ'
7-4
Concurrency Issues
In other words, both programs are reading through the same table, one fetching certain rows and the other changing the same rows. The following possibilities are concerned with what happens next:
1.
The other program nishes its update before your program fetches its rst row. Your program shows you only updated rows. Your program fetches every row before the other program has a chance to update it. Your program shows you only original rows. After your program fetches some original rows, the other program catches up and goes on to update some rows that your program has yet to read; then it executes the COMMIT WORK statement. Your program might return a mixture of original rows and updated rows.
2.
3.
4.
Same as number 3, except that after updating the table, the other program issues a ROLLBACK WORK statement. Your program can show you a mixture of original rows and updated rows that no longer exist in the database.
The rst two possibilities are harmless. In number 1, the update is complete before your query begins. It makes no difference whether it nished a microsecond or a week ago. In number 2, your query is, in effect, complete before the update begins. The other program might have been working just one row behind yours, or it might not start until tomorrow night; it does not matter. The second pair of chances, however, can be very important to the design of some applications. In number 3, the query returns a mix of updated and original data. That can be a negative thing in some applications. In others, for instance, one that is taking an average of all prices, it might not matter at all. In number 4, it can be disastrous if a program returns some rows of data that, because their transaction was cancelled, can no longer be found in the table.
7-5
How Locks Work
Another concern arises when your program uses a cursor to update or delete the last-fetched row. Erroneous results occur with the following sequence of events:
s s s
Your program fetches the row. Another program updates or deletes the row. Your program updates or deletes WHERE CURRENT OF names.
You control concurrent events such as these using the locking and isolation level features of the database server.
How Locks Work

The INFORMIX-OnLine Dynamic Server database server supports a complex, exible set of locking features that is described in this section. Some of these locking features work differently on an INFORMIX-SE database server. (See Chapter 1 of the Informix Guide to SQL: Reference for a summary of the differences between locking in SE and OnLine database servers.)
Kinds of Locks
INFORMIX-OnLine Dynamic Server supports the following kinds of locks,
which it uses in different situations: shared A shared lock reserves its object for reading only. It prevents the object from changing while the lock remains. More than one program can place a shared lock on the same object. An exclusive lock reserves its object for the use of a single program. It is used when the program intends to change the object. An exclusive lock cannot be placed where any other kind of lock exists. Once one has been placed, no other lock can be placed on the same object.
exclusive
7-6
Lock Scope
promotable
A promotable lock establishes the intent to update. It can only be placed where no other promotable or exclusive lock exists. Promotable locks can be placed on records that already have shared locks. When the program is about to change the locked object, the promotable lock can be promoted to an exclusive lock, but only if there are no other locks, including shared locks on the record at the time the lock would change from promotable to exclusive. If a shared lock was on the record when the promotable lock was set, the shared lock must be dropped before the promotable lock can be promoted to an exclusive lock.
Lock Scope
You can apply locks to entire databases, entire tables, disk pages, single rows, or index-key values. The size of the object being locked is referred to as the scope of the lock (also called the lock granularity). In general, the larger the scope of a lock, the more concurrency is reduced but the simpler programming becomes.
Database Locks
You can lock an entire database. The act of opening a database places a shared lock on the name of the database. A database is opened with the CONNECT, DATABASE, or CREATE DATABASE statements. As long as a program has a database open, the shared lock on the name prevents any other program from dropping the database or putting an exclusive lock on it. You can lock an entire database exclusively with the following statement:
DATABASE database name EXCLUSIVE
This statement succeeds if no other program has opened that database. Once the lock is placed, no other program can open the database, even for reading because its attempt to place a shared lock on the database name fails. A database lock is released only when the database closes. That can be done explicitly with the DISCONNECT or CLOSE DATABASE statements or implicitly by executing another DATABASE statement.
7-7
Lock Scope
Because locking a database reduces concurrency in that database to zero, it makes programming very simpleconcurrent effects cannot happen. However, you should lock a database only when no other programs need access. Database locking is often used before applying massive changes to data during off-peak hours.
Table Locks
You can lock entire tables. In some cases, this is done automatically. INFORMIX-OnLine Dynamic Server always locks an entire table while it performs any of the following statements:
s s s s s s
ALTER INDEX ALTER TABLE CREATE INDEX DROP INDEX RENAME COLUMN RENAME TABLE
The completion of the statement (or end of the transaction) releases the lock. An entire table also can be locked automatically during certain queries. You can use the LOCK TABLE statement to lock an entire table explicitly. This statement allows you to place either a shared lock or an exclusive lock on an entire table. A shared table lock prevents any concurrent updating of that table while your program is reading from it. INFORMIX-OnLine Dynamic Server achieves the same degree of protection by setting the isolation level, as described in the next section, which allows greater concurrency than using a shared table lock. However, all Informix database servers support the LOCK TABLE statement. An exclusive table lock prevents any concurrent use of the table. This has a serious effect on performance if many other programs are contending for the use of the table. As with an exclusive database lock, an exclusive table lock is often used when massive updates are applied during off-peak hours. For example, some applications do not update tables during the hours of peak use. Instead, they write updates to an update journal. During off-peak hours, that journal is read and all updates are applied in a batch.
The Duration of a Lock Page, Row, and Key Locks

One row of a table is the smallest object that can be locked. A program can lock one row or a selection of rows while other programs continue to work on other rows of the same table.
INFORMIX-OnLine Dynamic Server stores data in units called disk pages. (Its
disk-storage methods are described in detail in the INFORMIX-OnLine Dynamic Server Administrators Guide. Tips for optimizing tables on disk storage can be found in the INFORMIX-OnLine Dynamic Server Performance Guide.) A disk page contains one or more rows. In some cases, it is better to lock a disk page than to lock individual rows on it. You choose between locking by rows or locking by pages when you create the table. INFORMIX-OnLine Dynamic Server supports a clause, LOCK MODE, to specify either page or row locking. You can specify lock mode in the CREATE TABLE statement and later change it with the ALTER TABLE statement. (Other Informix database servers do not offer the choice; they lock by row or by page, whichever makes the better implementation.) Page and row locking are used identically. Whenever INFORMIX-OnLine Dynamic Server needs to lock a row, it locks either the row itself or the page it is on, depending on the lock mode established for the table. In certain cases, the database server has to lock a row that does not existin effect, it locks the place in the table where the row would be if it did exist. The database server does this by placing a lock on an index-key value. Key locks are used identically to row locks. When the table uses row locking, key locks are implemented as locks on imaginary rows. When it uses page locking, a key lock is placed on the index page that contains the key or that would contain the key if it existed.
The Duration of a Lock

The program controls the duration of a database lock. A database lock is released when the database closes. The duration of a table lock depends on whether the database uses transactions. If it does not (that is, if no transaction log exists and the COMMIT WORK statement is not used), a table lock remains until it is removed by the execution of the UNLOCK TABLE statement.
7-9
Locks While Modifying
The duration of table, row, and index locks depends on what SQL statements are used and on whether transactions are in use. When transactions are used, the end of a transaction releases all table, row, page, and index locks. This is an important point: When a transaction ends, all locks are released.
Locks While Modifying

When the database server fetches a row through an update cursor, it places a promotable lock on the fetched row. If this succeeds, the database server knows that no other program can alter that row. Because a promotable lock is not exclusive, other programs can continue to read the row. This helps performance because the program that fetched the row can take some time before it issues the UPDATE or DELETE statement, or it can simply fetch the next row. When it is time to modify a row, the database server obtains an exclusive lock on the row. If it already had a promotable lock, it changes it to exclusive status. The duration of an exclusive row lock depends on whether transactions are in use. If they are not in use, the lock is released as soon as the modied row is written to disk. When transactions are in use, all such locks are held until the end of the transaction. This prevents other programs from using rows that might be rolled back to their original state. When transactions are in use, a key lock is used whenever a row is deleted. This prevents the following error from occurring:
s s s
Program A deletes a row. Program B inserts a row having the same key. Program A rolls back its transaction, forcing the database server to restore its deleted row. What is to be done with the row inserted by program B?
By locking the index, the database server prevents a second program from inserting a row until the rst program commits its transaction. The locks placed while reading a row are controlled by the current isolation level, which is discussed in the next section.
Setting the Isolation Level
Setting the Isolation Level

The isolation level is the degree to which your program is isolated from the concurrent actions of other programs. INFORMIX-OnLine Dynamic Server offers a choice of isolation levels. It implements them by setting different rules for how a program uses locks when it is reading. (This does not apply to reads performed on update cursors.) You set the isolation level using either the SET ISOLATION or SET TRANSACTION statement. Isolation levels can only be set with the INFORMIX-OnLine Dynamic Server database servers. The SET TRANSACTION statement also provides the ability to set access modes in either INFORMIX-OnLine Dynamic Server or INFORMIX-SE. For more information about access modes, see Controlling Data Modication with Access Modes on page 7-16.
Comparing SET TRANSACTION with SET ISOLATION

The SET TRANSACTION statement complies with ANSI SQL-92. This statement is similar to the Informix SET ISOLATION statement; however, the SET ISOLATION statement is not ANSI-compliant and does not provide access modes. The isolation levels that you can set with the SET TRANSACTION statement are comparable to the isolation levels that you can set with the SET ISOLATION statement, as shown in the following table:
SET TRANSACTION Correlates to SET ISOLATION
Read Uncommitted Read Committed Not Supported (ANSI) Repeatable Read Serializable
Dirty Read Committed Read Cursor Stability (Informix) Repeatable Read (Informix) Repeatable Read
7-11
ANSI Read Uncommitted and Informix Dirty Read Isolation
The major difference between the SET TRANSACTION and SET ISOLATION statements is the behavior of the isolation levels within transactions. The SET TRANSACTION statement can be issued only once for a transaction. Any cursors opened during that transaction are guaranteed to get that isolation level (or access mode if you are dening an access mode). With the SET ISOLATION statement, after a transaction is started, you can change the isolation level more than once within the transaction. The following examples show both the SET ISOLATION and SET TRANSACTION statements: SET ISOLATION
EXEC EXEC EXEC EXEC EXEC EXEC SQL BEGIN WORK; SQL SET ISOLATION TO DIRTY READ; SQL SELECT ... ; SQL SET ISOLATION TO REPEATABLE READ; SQL INSERT ... ; SQL COMMIT WORK; -- Executes without error
SET TRANSACTION
EXEC SQL BEGIN WORK; EXEC SQL SET TRANSACTION ISOLATION LEVEL TO SERIALIZABLE; EXEC SQL SELECT ... ; EXEC SQL SET TRANSACTION ISOLATION LEVEL TO READ COMMITTED; Error 876: Cannot issue SET TRANSACTION more than once in an active transaction.
ANSI Read Uncommitted and Informix Dirty Read Isolation

The simplest isolation level, ANSI Read Uncommitted and Informix Dirty Read, amounts to virtually no isolation. When a program fetches a row, it places no locks and it respects none; it simply copies rows from the database without regard for what other programs are doing. A program always receives complete rows of data; even under ANSI Read Uncommitted or Informix Dirty Read isolation, a program never sees a row in which some columns have been updated and some have not. However, a program using ANSI Read Uncommitted or Informix Dirty Read isolation sometimes reads updated rows before the updating program ends its transaction. If the updating program later rolls back its transaction, the reading program processed data that never really existed (number 4 in the list of concurrency issues on page 7-5).
7-12
ANSI Read Committed and Informix Committed Read Isolation
ANSI Read Uncommitted or Informix Dirty Read is the most efcient isolation level. The reading program never waits and never makes another program wait. It is the preferred level in any of the following cases:
s
All tables are static; that is, concurrent programs only read and never modify data. The database is held in an exclusive lock. It is certain that only one program is using the database.
s s
ANSI Read Committed and Informix Committed Read Isolation

When a program requests the ANSI Read Committed or Informix Committed Read isolation level, INFORMIX-OnLine Dynamic Server guarantees that it never returns a row that is not committed to the database. This prevents reading data that is not committed and that is subsequently rolled back.
ANSI Read Committed or Informix Committed Read is implemented very simply. Before fetching a row, the database server tests to determine whether an updating process placed a lock on the row; if not, it returns the row. Because rows that are updated but not committed have locks on them, this test ensures that the program does not read uncommitted data. ANSI Read Committed or Informix Committed Read does not actually place a lock on the fetched row; hence, it is almost as efcient as ANSI Read Uncommitted or Informix Dirty Read. It is appropriate for use when each row of data is processed as an independent unit, without reference to other rows in the same or other tables.
Informix Cursor Stability Isolation

The next level, Cursor Stability, is available only with the Informix SQL statement SET ISOLATION. When it is in effect, the database server places a lock on the latest row fetched. It places a shared lock for an ordinary cursor or a promotable lock for an update cursor. Only one row is locked at a time; that is, each time a row is fetched, the lock on the previous row is released (unless that row is updated, in which case the lock holds until the end of the transaction).
7-13
Informix Cursor Stability Isolation
Cursor Stability ensures that a row does not change while the program examines it. This is important when the program updates some other table based on the data it reads from this row. Because of Cursor Stability, the program is assured that the update is based on current information. It prevents the use of stale data. Here is an example to illustrate this point. In terms of the demonstration database, Program A wants to insert a new stock item for manufacturer Hero (HRO). Concurrently, program B wants to delete manufacturer HRO and all stock associated with it. The following sequence of events can occur:
1.
Program A, operating under Cursor Stability, fetches the HRO row from the manufact table to learn the manufacturer code: This places a shared lock on the row. Program B issues a DELETE statement for that row. Because of the lock, the database server makes the program wait. Program A inserts a new row in the stock table using the manufacturer code it obtained from the manufact table. Program A closes its cursor on the manufact table or reads a different row of it, releasing its lock. Program B, released from its wait, completes the deletion of the row and goes on to delete the rows of stock that use manufacturer code HRO, including the row just inserted by Program A.
2. 3. 4. 5.
If Program A used a lesser level of isolation, the following sequence could have happened:
1. 2. 3. 4. 5. 6.
Program A reads the HRO row of the manufact table to learn the manufacturer code. No lock is placed. Program B issues a DELETE statement for that row. It succeeds. Program B deletes all rows of stock that use manufacturer code HRO. Program B ends. Program A, not aware that its copy of the HRO row is now invalid, inserts a new row of stock using the manufacturer code HRO. Program A ends.
7-14
ANSI Serializable, ANSI Repeatable Read and Informix Repeatable Read Isolation
At the end, a row occurs in stock that has no matching manufacturer code in manufact. Furthermore, Program B apparently has a bug; it did not delete the rows it was supposed to delete. The use of the Cursor Stability isolation level prevents these effects. (It is possible to rearrange the preceding scenario so that it fails even with Cursor Stability. All that is required is for Program B to operate on tables in the reverse sequence to Program A. If Program B deletes from stock before it removes the row of manufact, no degree of isolation can prevent an error. Whenever this kind of error is possible, it is essential that all programs involved use the same sequence of access.) Because Cursor Stability locks only one row at a time, it restricts concurrency less than does a table lock or database lock.
ANSI Serializable, ANSI Repeatable Read and Informix Repeatable Read Isolation
The denitions for ANSI Serializable, ANSI Repeatable Read, and Informix Repeatable Read isolation levels are all the same. The Repeatable Read isolation level asks the database server to put a lock on every row the program examines and fetches. The locks that are placed are shareable for an ordinary cursor and promotable for an update cursor. The locks are placed individually as each row is examined. They are not released until the cursor closes or a transaction ends. Repeatable Read allows a program that uses a scroll cursor to read selected rows more than once and to be sure that they are not modied or deleted between readings. (Scroll cursors are described in Chapter 5, Programming with SQL.) No lower isolation level guarantees that rows still exist and are unchanged the second time they are read. Repeatable Read isolation places the largest number of locks and holds them the longest. Therefore, it is the level that reduces concurrency the most. If your program uses this level of isolation, you must think carefully about how many locks it places, how long they are held, and what the effect can be on other programs.
7-15
Controlling Data Modication with Access Modes
In addition to the effect on concurrency, the large number of locks can be a problem. The database server records the number of locks by each program in a lock table. If the maximum number of locks is exceeded, the lock table lls up and the database server cannot place a lock. An error code is returned. The person who administers an INFORMIX-OnLine Dynamic Server system can monitor the lock table and tell you when it is heavily used. Serializable is automatically used as the isolation level in an ANSI-compliant database. Serializable is required to ensure operations behave in accordance with the ANSI standard for SQL.
Controlling Data Modication with Access Modes

Both INFORMIX-OnLine Dynamic Server and INFORMIX-SE support access modes. Access modes affect read and write concurrency for rows within transactions and are set with the SET TRANSACTION statement. You can use access modes to control data modication among shared les. Transactions are read-write by default. If you specify that a transaction is read-only, that transaction cannot do the following tasks:
s s s
Insert, delete, or update table rows Enable or disable constraints, triggers, or indexes Create, alter, or drop any database object such as schemas, tables, temporary tables, indexes, or stored procedures Grant or revoke privileges Update statistics Rename columns or tables
s s s
Read-only access mode prohibits updates. You can execute stored procedures in a read-only transaction as long as the procedure does not try to perform any restricted statements.
7-16
Setting the Lock Mode
Setting the Lock Mode

The lock mode determines what happens when your program encounters locked data. One of the following situations occur when a program attempts to fetch or modify a locked row:
s
The program receives an immediate return from the database server with an error code in SQLCODE or SQLSTATE. The program is suspended until the lock is removed by the program that placed it. The program is suspended for a time and then, if the lock is not removed, it receives an error-return code from the database server.
You choose among these results with the SET LOCK MODE command.
Waiting for Locks

If you prefer to wait (and this is the best choice for many applications), execute the following command:
SET LOCK MODE TO WAIT
When this lock mode is set, your program usually ignores the existence of other concurrent programs. When it needs to access a row that another program has locked, your program waits until the lock is removed, then proceeds. The delays are usually imperceptible.
Not Waiting for Locks

The disadvantage of waiting for locks is that the wait might become very long (although properly designed applications should hold their locks very briey). When the possibility of a long delay is not acceptable, a program can execute the following command:
SET LOCK MODE TO NOT WAIT
When the program requests a locked row, it immediately receives an error code (for example, error -107, Record is locked), and the current SQL statement terminates. It is up to the program to roll back its current transaction and try again.
Programming for a Multiuser Environment 7-17
Waiting a Limited Time
The initial setting is not waiting when a program starts up. If you are using SQL interactively and see an error related to locking, set the lock mode to wait. If you are writing a program, consider making that one of the rst embedded SQL commands that the program executes.
Waiting a Limited Time

When you use INFORMIX-OnLine Dynamic Server, you have an additional choice: You can ask the database server to set an upper limit on a wait. You can issue the following command:
SET LOCK MODE TO WAIT 17
This places an upper limit of 17 seconds on the length of any wait. If a lock is not removed in that time, the error code is returned.
Handling a Deadlock
A deadlock is a situation in which a pair of programs block the progress of each other. Each program has a lock on some object that the other program wants to access. A deadlock arises only when all programs concerned set their lock modes to wait for locks.
INFORMIX-OnLine Dynamic Server detects deadlocks immediately
when they involve only data at a single network server. It prevents the deadlock from occurring by returning an error code (error -143 ISAM error: deadlock detected) to the second program to request a lock. The error code is the one the program receives if it sets its lock mode to not wait for locks. Thus, if your program receives an error code related to locks even after it sets lock mode to wait, you know the cause is an impending deadlock.
7-18
Handling External Deadlock
Handling External Deadlock

A deadlock can also occur between programs on different database servers. In this case, INFORMIX-OnLine Dynamic Server cannot instantly detect the deadlock. (Perfect deadlock detection requires excessive communications trafc among all database servers in a network.) Instead, each database server sets an upper limit on the amount of time that a program can wait to obtain a lock on data at a different database server. If the time expires, the database server assumes that a deadlock was the cause and returns a lockrelated error code. In other words, when external databases are involved, every program runs with a maximum lock-waiting time. The maximum is set for the database server and can be changed by the database administrator.
Simple Concurrency
If you are not sure which choice to make concerning locking and concurrency, and if your application is straightforward, have your program execute the following commands when it starts up (immediately after the rst DATABASE statement):
SET LOCK MODE TO WAIT SET ISOLATION TO REPEATABLE READ
Ignore the return codes from both statements. Proceed as if no other programs exist. If no performance problems arise, you do not need to read this section again.
7-19
Locking with Other Database Servers
Locking with Other Database Servers

INFORMIX-OnLine Dynamic Server manages its own locking so that it can
provide the different kinds of locks and levels of isolation described in the preceding topics. Other Informix database servers implement locks using the facilities of the host operating system and cannot provide the same conveniences. Some host operating systems provide locking functions as operating system services. In these systems, database servers support the SET LOCK MODE statement. Some host operating systems do not provide kernel-locking facilities. In these systems, the database server performs its own locking based on small les that it creates in the database directory. These les have the sufx .lok. You can tell the kind of system in which your database server is running by executing the SET LOCK MODE statement and testing the error code, as shown in the following fragment of INFORMIX-ESQL/C code:
#define LOCK_ONLINE 1 #define LOCK_KERNEL 2 #define LOCK_FILES 3 int which_locks() { int locktype; locktype = LOCK_FILES; EXEC SQL set lock mode to wait 30; if (sqlca.sqlcode == 0) locktype = LOCK_ONLINE; else { EXEC SQL set lock mode to wait; if (sqlca.sqlcode == 0) locktype = LOCK_KERNEL; } /* restore default condition */ EXEC SQL set lock mode to not wait; return(locktype); }
If the database server does not support the SET LOCK MODE statement, your program is effectively always in NOT WAIT mode; that is, whenever it tries to lock a row that is locked by another program, it receives an error code immediately.
Isolation While Reading
Isolation While Reading

Informix database servers other than INFORMIX-OnLine Dynamic Server do not normally place locks when fetching rows. Nothing comparable exists to the shared locks used by OnLine to implement the Cursor Stability isolation level. If your program fetches a row with a singleton SELECT statement or through a cursor that is not declared FOR UPDATE, the row is fetched immediately, regardless of whether it is locked or modied by an unnished transaction. This design produces the best performance, especially when locks are implemented by writing notes in disk les, but you must be aware that the program can read rows that are modied by uncommitted transactions. You can obtain the effect of Cursor Stability isolation by declaring a cursor FOR UPDATE, and then using it for input. Whenever the database server fetches a row through an update cursor, it places a lock on the fetched row. (If the row is already locked, the program waits or receives an error, depending on the lock mode.) When the program fetches another row without updating the current one, the lock on the current row is released and the new row is locked. You can be sure by fetching through an update cursor, that the fetched row is locked as long as you use it. (The row cannot become stale.) You are also assured of fetching only committed data because locks on rows that are updated are held until the end of the transaction. Depending on the host operating system and the database server, you might experience a performance penalty for using an update cursor this way.
Locking Updated Rows

When a cursor is declared FOR UPDATE, locks are handled as follows: Before a row is fetched, it is locked; if it cannot be locked, the program waits or returns an error. The next time a fetch is requested, the database server notes whether the current row is modied (using either the UPDATE or DELETE statement with WHERE CURRENT OF) and whether a transaction is in progress. If both these things are true, the lock on the row is retained. Otherwise, the lock is released.
7-21
Hold Cursors
So if you perform updates within a transaction, all updated rows remain locked until the transaction ends. Rows that are not updated are locked only while they are current. Rows updated outside a transaction or in a database that does not use transaction logging, are also unlocked as soon as another row is fetched.
Hold Cursors
When transaction logging is used, the database server guarantees that anything done within a transaction can be rolled back at the end of it. To do this reliably, the database server normally applies the following rules:
s s
All cursors are closed by ending a transaction. All locks are released by ending a transaction.
These rules are normal with all database systems that support transactions, and for most applications they do not cause any trouble. However, circumstances exist where using standard transactions with cursors are not possible. For example, a situation is sketched in Figure 7-1 which works ne without transactions. However, when transactions are added, closing the cursor conicts with using two cursors simultaneously.
DECLARE master CURSOR FOR ... DECLARE detail CURSOR FOR ... FOR UPDATE OPEN master LOOP: FETCH master INTO ... IF (the fetched data is appropriate) THEN BEGIN WORK OPEN detail USING data read from master FETCH detail ... UPDATE ... WHERE CURRENT OF detail COMMIT WORK END IF END LOOP CLOSE MASTER
Figure 7-1 A pseudocode sketch of one common form of database application
7-22
Summary
In this design, one cursor is used to scan a table. Selected records are used as the basis for updating a different table. The problem is that when each update is treated as a separate transaction (as shown in the pseudocode in Figure 7-1 on page 7-22), the COMMIT WORK statement following the UPDATE closes all cursors, including the master cursor. The simplest alternative is to move the COMMIT WORK and BEGIN WORK statements to be the last and rst ones, respectively, so that the entire scan over the master table is one large transaction. This is sometimes possible, but it may become impractical if many rows need to be updated. The number of locks can be too large, and they are held for the duration of the program. A solution supported by Informix database servers is to add the keywords WITH HOLD to the declaration of the master cursor. Such a cursor is referred to as a hold cursor and is not closed at the end of a transaction. The database server still closes all other cursors, and it still releases all locks, but the hold cursor remains open until it is explicitly closed. Before you attempt to use a hold cursor, you must be sure that you understand the locking mechanism described here, and you must also understand the programs that are running concurrently. The reason is that whenever COMMIT WORK is executed, all locks are released, including any locks placed on rows fetched through the hold cursor. This has little importance if the cursor is used as intended, for a single forward scan over a table. However, you are allowed to specify WITH HOLD for any cursor, including update cursors and scroll cursors. Before you do this, you must understand the implications of the fact that all locks (including locks on entire tables) are released at the end of a transaction.
Summary
Whenever multiple programs have access to a database concurrently (and when at least one of them can modify data), all programs must allow for the possibility that another program can change the data even as they read it. The database server provides a mechanism of locks and isolation levels that usually allow programs to run as if they were alone with the data.
7-23
Designing and Managing Databases
Section II
Chapter
Building Your Data Model
8
. . . . . . 8-3 8-4 8-5 8-5 8-5 8-6 8-7 8-9 8-9 8-10 8-10 8-11 8-11 8-16 8-17 8-17 8-17 8-18 8-19 8-19 8-21 8-21 8-23 8-24 8-25 8-26 8-26 8-28 8-29
Why Build a Data Model . . . . . . . . . Entity-Relationship Data Model Overview .
. .
. .
. .
. .
. .
Identifying and Dening Your Principal Data Objects . . . . . . . Discovering Entities . . . . . . . . . . . . . . . . . Choosing Possible Entities . . . . . . . . . . . . . Pruning Your List of Entities . . . . . . . . . . . . . The Telephone-Directory Example . . . . . . . . . . . Diagramming Your Entities . . . . . . . . . . . . . Dening the Relationships . . . . . . . . . . . . . . . Connectivity . . . . . . . . . . . . . . . . . . Existence Dependency . . . . . . . . . . . . . . . Cardinality . . . . . . . . . . . . . . . . . . . Discover the Relationships . . . . . . . . . . . . . Diagramming Your Relationships . . . . . . . . . . . Identifying Attributes . . . . . . . . . . . . . . . . How to Identify an Attribute . . . . . . . . . . . . . Selecting Attributes for Your Entities . . . . . . . . . . Listing Your Attributes . . . . . . . . . . . . . . . About Entity Occurrences . . . . . . . . . . . . . . Diagramming Your Data Objects . . . . . . . . . . . . . . How You Read Entity-Relationship Diagrams . . . . . . . The Telephone-Directory Example . . . . . . . . . . . Translating E-R Data Objects Into Relational Constructs . Rules for Dening Tables, Rows, and Columns . . . Placing Constraints on Columns . . . . . . Determining Keys for Tables . . . . . . . . . Primary Keys . . . . . . . . . . . . . Foreign Keys (Join Columns) . . . . . . . . Adding Keys to the Telephone-Directory Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resolving Your Relationships . . . . . . Resolving m:n Relationships . . . . Resolving Other Special Relationships Normalizing Your Data Model . . . . First Normal Form . . . . . Second Normal Form . . . . Third Normal Form . . . . . Summary of Normalization Rules Summary . . . . . . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
8-30 8-30 8-32 8-33 8-34 8-36 8-36 8-37 8-38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-2
T
s
he rst step in creating a database is to construct a data modela precise, complete denition of the data to be stored. This chapter contains a cursory overview of one method of doing this. The following chapters describe how to implement a data model once you design it. To understand the material in this chapter, you should have a basic understanding of SQL and relational database theory.
Why Build a Data Model

You may already have an idea of a database. If you use some type of formal notation to build your data model, you can help your design in two ways: It makes you think through the data model completely. A mental model often contains unexamined assumptions; formalizing the design reveals these points.
s
It is easier to communicate your design to other people. A formal statement makes the model explicit, so that others can return comments and suggestions in the same form.
8-3
Entity-Relationship Data Model Overview
Entity-Relationship Data Model Overview

Different books present different formal methods of modeling data. Most methods force you to be thorough and precise. If you have already learned a method, by all means use it. This chapter presents a summary of the entity-relationship (E-R ) data model, a modeling method taught in training courses presented by Informix. The E-R modeling method is carried out in the following steps:
1. 2. 3. 4. 5.
Identify and dene the principal data objects (entities, relationships, and attributes). Diagram the data objects using the entity-relationship approach. Translate your entity-relationship data objects into relational constructs. Resolve the logical data model. Normalize the logical data model.
Steps 1-5 are discussed in this chapter. Chapter 9, Implementing Your Data Model, discusses a nal stepconverting your logical data model to a physical schema. The end product of data modeling is a fully dened database design encoded in a diagram similar to the one shown in Figure 8-16 on page 8-28, which shows the nal set of tables for a personal telephone directory. The personal telephone directory is an example developed in this chapter. It is used rather than the stores7 database used in the rest of this book because it is small enough to be developed completely in one chapter but large enough to show the entire method.
8-4
Identifying and Dening Your Principal Data Objects
Identifying and Dening Your Principal Data Objects

The rst step in building an entity-relationship data model is to identify and dene your principal data objects. The principal data objects are entities, relationships, and attributes.
Discovering Entities
An entity is a principal data object that is of signicant interest to the user. It is usually a person, place, thing, or event to be recorded in the database. If the data model were a language, entities would be its nouns. The stores7 database contains the following entities: customer, orders, items, stock, catalog, cust_calls, call_type, manufact, and state. The rst step in modeling is to choose the entities to record. Most of the entities that you choose will become tables in the model.
Choosing Possible Entities

If you have an idea for your database, you can probably list several entities immediately. However, if other people use the database, you should poll them for their understanding of what fundamental things the database should contain. Make a preliminary list of all the entities you can identify. Interview the potential users of the database for their opinions about what must be recorded in the database. Determine basic characteristics for each entity, such as there must be at least one address associated with a name. All the decisions you make in determining your entities become your business rules. The Telephone-Directory Example on page 8-7 provides some of the business rules for the example shown in this chapter. Later, when you normalize your data model, some of the entities may expand or become other data objects. See Normalizing Your Data Model on page 8-33 for additional information.
8-5
Discovering Entities Pruning Your List of Entities

When the list of entities seems complete, prune it by making sure that each one has the following qualities:
s
It is signicant. List only entities that are important to the users of the database and worth the trouble and expense of computer tabulation.
It is generic. List only types of things, not individual instances. For instance, symphony might be an entity, but Beethovens Fifth would be an entity instance or entity occurrence.
It is fundamental. List only entities that exist independently, without needing something else to explain them. Anything you could call a trait, a feature, or a description is not an entity. For example, a part number is a feature of the fundamental entity called part. Also, do not list things that you can derive from other entities; for example, avoid any sum, average, or other quantity that you can calculate in a SELECT expression.
It is unitary. Be sure that each entity you name represents a single classthat it cannot be broken down into subcategories, each with its own features. In planning the telephone-directory model (see The Telephone-Directory Example on page 8-7) an apparently simple entity, the telephone number, turns out to consist of three categories, each with different features.
These choices are neither simple nor automatic. To discover the best choice of entities, you must think deeply about the nature of the data you want to store. Of course, that is exactly the point of making a formal data model. The following section describes the example shown in this chapter in further detail.
8-6
Discovering Entities The Telephone-Directory Example

Suppose that you create a database that computerizes a personal telephone directory. The database model must record the names, addresses, and telephone numbers of people and organizations that its user deals with for business and pleasure. The rst step is to dene the entities, and the rst thing you might do is look carefully at a page from a telephone directory to see what entities are there.
Figure 8-1 Part of a page from a telephone directory
NAME ADDRESS
866 Gage Rd. Klamath Falls OR 97601
PHONE
NAME ADDRESS
429 Bridge Way Seattle, WA 98103
PHONE
Thomas Morrison 503-776-3428
Catherine Morgan 206-789-5396
NAME
Thomas Morrison
PHONE
ADDRESS
NAME
Thomas Morrison
PHONE
ADDRESS
N NAME PHONE O Norman Dearborn (206)598-8189 P Q ADDRESS Morganthaler Industries R S 12558 E. 10th Ave. Seattle, WA T 98102 FAX: 206 598-6872 NAME PHONE U Thomas Morrison 503-256-6031 V ADDRESS W 866 Gage Rd. X Klamath Falls, OR 97601 Y Z
8-7
Discovering Entities
The physical form of the existing data can be misleading. Do not let the layout of pages and entries in the telephone directory mislead you into trying to specify an entity that represents one entry in the booksome kind of alphabetized record with elds for name, number, and address. Remember it is not the medium you want to model, it is the data. At rst glance, the entities recorded in a telephone directory include the following items:
s s s
Names (of persons and organizations) Addresses Telephone numbers
Do these entities meet the earlier criteria? They are clearly signicant to the model and are generic. Are they fundamental? A good test is to ask if an entity can vary in number independently of any other entity. After thinking about it, you realize that a telephone directory sometimes lists people who have no number or current address (people who move or change jobs). A telephone directory also can list both addresses and numbers that are used by more than one person. All three of these entities can vary in number independently; that strongly suggests they are fundamental, not dependent. Are they unitary? Names can be split into personal names and corporate names. After thinking about it, you decide that all names should have the same features in this model; that is, you do not plan to record different information about a company than you would about a person. Likewise, you decide only one kind of address exists; no need exists to treat home addresses differently from business ones. However, you also realize that more than one kind of telephone number exists, three. Voice numbers are answered by a person, fax numbers connect to a fax machine, and modem numbers connect to a computer. You decide that you want to record different information about each kind of number, so these three are different entities.
8-8
Dening the Relationships
For the personal telephone-directory example, you decide that you want to keep track of the following entities:
s s s s s
Name Address (mailing) Telephone number (voice) Telephone number (fax) Telephone number (modem)
Diagramming Your Entities

A section in this chapter will teach you how to use the entity-relationship diagrams. For now, create a separate, rectangular box for each entity in the telephone-directory example. You will learn how to put the entities together with relationships in Diagramming Your Data Objects on page 8-19.
Figure 8-2 Entities in the personal telephonedirectory example
name
address
voice
fax
modem

After you choose your entities, you need to consider the relationships between them. Relationships are not always obvious, but all the ones worth recording must be found. The only way to ensure that all the relationships are found is to exhaustively list all possible relationships. You must consider every pair of entities A and B and ask, What is the relationship between an A and a B? A relationship is an association between two entities. Usually, a verb or preposition connecting two entities implies a relationship. A relationship between entities is described in terms of connectivity, existence dependency, and cardinality.
8-9
Dening the Relationships Connectivity

Connectivity refers to the number of entity instances. An entity instance is a particular occurrence of an entity. The three types of connectivity are one-toone (written 1:1), one-to-many (written 1:n), and many-to-many (written m:n) shown in Figure 8-3.
Figure 8-3 Connectivity in relationships
one-to-one
one-to-many
many-to-many
For example, in the telephone-directory example, an address can be associated with more than one name. The connectivity for the relationship between the name and address entities is one-to-many (1:n).
Existence Dependency
Existence dependency describes whether an entity in a relationship is optional or mandatory. Analyze your business rules to identify whether an entity must exist in a relationship. For example, your business rules may dictate that an address must be associated with a name. This would make the existence dependency for the relationship between the name and address entities mandatory. An example of an optional existence dependency could be a business rule that said a person may or may not have children.
8-10
Dening the Relationships Cardinality

Cardinality places a constraint on the number of times an entity can appear in a relationship. The cardinality of a 1:1 relationship is always one. But the cardinality of a 1:n relationship is open; n could be any number. If you need to place an upper limit on n, you do it by specifying a cardinality for the relationship. For example, in a store sale example, you could limit the number of sale items that a customer can purchase at one time. You usually place cardinality constraints through your application program or through stored procedures. For additional information about cardinality, see any entity-relationship data modeling text. References to two data modeling books are included in the Summary on page 8-38.
Discover the Relationships

A compact way to discover the relationships is to prepare a matrix that names all the entities on the rows and again on the columns. Figure 8-4 is a matrix that reects the entities for the personal telephone directory.
name name address number (voice) number (fax) number (modem) address number (voice) number (fax) number (modem)
Figure 8-4 A matrix that reects the entities for a personal telephone directory
8-11
You can ignore the lower triangle of the matrix, as indicated by the shaded area. You must consider the diagonal cells; that is, you must ask the question What is the relationship between an A and another A? In this model, the answer is always none. No relationship exists between a name and a name or an address and another address, at least none worth recording in this model. When a relationship exists between an A and another A, you have found a recursive relationship. (See Resolving Other Special Relationships on page 8-32.) For all cells for which the answer is clearly none, write none in the matrix. Now the matrix looks like Figure 8-5.
name name address number (voice) number (fax) number (modem) none none address number (voice) number (fax) number (modem)
Figure 8-5 A matrix with initial relationships included: No entities relate to themselves
none none none
Although no entities relate to themselves in this model, this is not always true in other models . A typical example is an employee who is the manager of another employee. Another example occurs in manufacturing, when a part entity is a component of another part.
8-12
In the remaining cells, you write the connectivity relationship that exists between the entity on the row and the entity on the column. The following kinds of relationships are possible:
s
One-to-one (1:1), in which never more than one entity A exists for one entity B and never more than one B for one A. One-to-many (1:n), in which never more than one entity A exists, but there can be several entities B related to it (or vice versa). Many-to-many (m:n), in which several entities A can be related to one B and several entities B can be related to one A.
One-to-many relationships are the most common. Examples of one-to-many and many-to-many relationships are shown in the telephone-directory model. As Figure 8-5 on page 8-12 shows, the rst unlled cell represents the relationship between names and addresses. What connectivity lies between these entities? You can ask yourself, How many names can be associated with an address? A name (you decide) can have zero or one address but no more than one. You write 0-1 opposite name and below address, as shown in Figure 8-6:
name address
Figure 8-6 Relationship between name and address
name
none
0-1
Ask yourself how many addresses can be associated with a name. You decide that an address can be associated with more than one name. For example, you can know several people at one company or more than two people who live at the same address.
8-13
Can an address be associated with zero names? That is, should it be possible for an address to exist when no names use it? You decide that yes, it can. Below address and opposite name, you write 0-n, as shown in Figure 8-7:
Figure 8-7 Relationship between address and name
name name none
address 0-n
0-1
If you decide that an address could not exist without being associated with at least one name, you write 1-n instead of 0-n. When the cardinality of a relationship is limited on either side to 1, it is a 1:n relationship. In this case, the relationship between names and addresses is a 1:n relationship. Now consider the next cell, the relationship between a name and a voice number. How many voice numbers can a name be associated with, one or more than one? Glancing at your telephone directory, you see that you may often have noted more than one telephone number for a personfor some busy salesman you have a home number, an ofce number, a paging number, and a car phone number. But there also can be names without associated numbers. You write 0-n opposite name and below number (voice), as shown in Figure 8-8:
name address 0-n 0-1 number (voice)
Figure 8-8 Relationship between name and number
name
none
0-n
8-14
What is the other side of this relationship? How many names can be associated with a voice number? You decide that only one name can be associated with a voice number. Can a number be associated with zero names? No, you decide; no point exists for recording a number unless it is used by someone. You write 1 under number (voice) and opposite name.
Figure 8-9 Relationship between number and name
name name none
address 0-n 0-1
number (voice) 1
0-n
Fill out the rest of the matrix in the same fashion, using the following decisions:
s
A name can be associated with more than one fax number; for example, a company can have several fax machines. Going the other way, a fax number can be associated with more than one name; for example, several people can use the same fax number. A modem number must be associated with exactly one name. (This is an arbitrary decree to complicate the example; pretend it is a requirement of the design.) However, a name can have more than one associated modem number; for example, a company computer can have several dial-up lines.
8-15
Although some relationship exists between a voice number and an address, a modem number and an address, and a fax number and an address in the real world, none needs to be recorded in this model. There already is an indirect relationship through name.
address number (voice) 1 0-n none none 0-n none none number (fax) 1-n 0-n none number (modem) 1
name name address number (voice) number (fax) number (modem) none
Figure 8-10 A completed matrix for a telephone directory
0-n 0-1 none
none none none
none
Other decisions reected in the matrix is that no relationship exists between a fax number and a modem number, between a voice number and a fax, or between a voice number and a modem number. You might disagree with some of these decisions (for example, why a relationship between voice numbers and modem numbers is not supported). For the sake of this example, these are our business rules.
Diagramming Your Relationships

For now, save the matrix that you created in this section. You will learn how to create an entity-relationship diagram in Diagramming Your Data Objects on page 8-19.
8-16
Identifying Attributes
Entities contain attributes, which are characteristics or modiers, qualities, amounts, or features. An attribute is a fact or nondecomposable piece of information about an entity. Later, when you represent an entity as a table, its attributes are added to the model as new columns.
How to Identify an Attribute

Before you can identify your attributes, you must identify your entities. After you determine your entities, ask yourself, what characteristics do you need to know about each entity? For example, in an address entity, you probably need information about street, city, and zipcode. Each of these characteristics of the address entity become attributes.
Selecting Attributes for Your Entities

In selecting attributes, choose ones that have the following qualities:
s
They are signicant. Include only attributes that are useful to the database users. They are direct, not derived. An attribute that can be derived from existing attributesfor instance, through an expression in a SELECT statementshould not be made part of the model. The presence of derived data greatly complicates the maintenance of a database. At a later stage of the design, you can consider adding derived attributes to improve performance, but at this stage you should exclude them. Performance improvements are discussed in the INFORMIX-OnLine Dynamic Server Performance Guide.
They are nondecomposable. An attribute can contain only single values, never lists or repeating groups. Composite values must be broken into separate attributes.
They contain data of the same type. For example, you would want to enter only date values in a birthday attribute, not names or telephone numbers.
8-17
The rules for dening attributes are the same as those for dening columns. For more information about dening columns, see Placing Constraints on Columns on page 8-25. The following attributes are added to the telephone-directory example to produce the diagram shown in Figure 8-15 on page 8-22:
s s
Street, city, state, and zip code are added to the address entity. Birth date is added to the name entity. Also added to the name entity are e-mail address, anniversary date, and childrens rst names. Type is added to the voice entity to distinguish car phones, home phones, and ofce phones. A voice number can be associated with only one voice type. The hours that a fax machine is attended is added to the fax entity. Whether a modem supports 300-, 1,200-, or 2,400-baud rates is added to the modem entity.
s s
Listing Your Attributes

For now, simply list the attributes for the telephone-directory example with the entities with which you think they belong. Your list should look something like Figure 8-11:
name fname lname bdate anniv email child1 child2 child3 address street city state zipcode voice vce_num vce_type fax fax_num oper_from oper_till modem mdm_num b300 b1200 b2400
Figure 8-11 Attributes for the telephone-directory example
8-18
Diagramming Your Data Objects About Entity Occurrences

An additional data object that you need to know about is the entity occurrence. Each row in a table represents a specic, single occurrence of the entity. For example, if customer is an entity, a customer table represents the idea of customer; in it, each row represents one specic customer, such as Sue Smith. Keep in mind that entities will become tables, attributes will become columns, and rows will become entity occurrences.
Diagramming Your Data Objects

At this point, you have already discovered and understood the entities and relationships in your database. That is the most important part of the relational database design process. Once you have determined the entities and relationships, you might nd it helpful to have a method for displaying your thought process during database design. Most data modeling methods provide some form of graphically displaying your entities and relationships. Informix uses the E-R diagram approach originally developed by C. R. Bachman. E-R diagrams serve the following purposes:
s s s
They model the information needs of an organization. They identify entities and their relationships. They provide a starting point for data denition (data ow diagrams). They provide an excellent source of documentation for application developers as well as database and system administrators. They create a logical design of the database which can be translated into a physical schema.
8-19
Several different styles of documenting E-R , diagrams exist. If you already have a style that you prefer, use it. A sample E-R diagram is shown in Figure 8-12:
name address
Figure 8-12 Symbols of an entity-relationship diagram
entity relationship
entity
Entities are represented by a box. Relationships are represented by a line connecting the entities. In addition, you use several graphical items to display the following features of relationships, as shown in Figure 8-13:
s
A circle across a relationship link indicates optionality in the relationship (zero instances). A small bar across a relationship link indicates that exactly one instance of the entity is associated with another entity (consider the bar as a 1). The crows feet represents many in your relationship.
Figure 8-13 The parts of a relationship in an entity-relationship diagram
optionality
ames
optionality
Addr
many
exactly one
8-20
Diagramming Your Data Objects How You Read Entity-Relationship Diagrams

You read the diagrams rst from left to right and then from right to left. In the case of the name-address relationship diagrammed in Figure 8-14, you read the relationships as follows: Names can be associated with zero or exactly one address; addresses can be associated with zero, one, or many names. can have zero or exactly 1
name address
Figure 8-14 Reading an entityrelationship diagram
can have zero or many
The Telephone-Directory Example

Figure 8-15 on page 8-22 shows the telephone-directory example and includes the entities, relationships, and attributes. This diagram includes the relationships that were established with the matrix. After studying the diagram symbols, compare the E-R diagram in Figure 8-15 with the matrix in Figure 8-10 on page 8-16. Verify for yourself that the relationships are the same in both gures.
8-21
A matrix such as Figure 8-10 on page 8-16 is a useful tool when you are rst designing your model because, in lling it out, you are forced to think of every possible relationship. However, the same relationships appear in a diagram such as Figure 8-15, and this type of diagram may be easier to read when you are reviewing an existing model.
lname fname bdate anniv email child1 child2 child3
address street city state zipcode
Figure 8-15 Preliminary entityrelationship diagram of the telephone-directory example
voice vce_num vce_type
fax fax_num oper_from oper_till
modem mdm_num b300 b1200 b2400
After the Diagram is Complete

The rest of the chapter describes the following tasks:
s
How to translate the entities, relationships, and attributes into relational constructs How to resolve the E-R data model How to normalize the E-R data model
s s
Chapter 9, Implementing Your Data Model, shows you how to create a database from the E-R data model.
8-22
Translating E-R Data Objects Into Relational Constructs
Translating E-R Data Objects Into Relational Constructs

All the data objects you have learned about so farentities, relationships, attributes, and entity occurrenceswill be translated into SQL tables, joins between tables, columns, and rows. The tables, columns, and rows of your database must t the rules found in Rules for Dening Tables, Rows, and Columns on page 8-24. Your data objects should t these rules before you normalize your data objects. Normalizing your data objects is accomplished by analyzing the dependencies between your entities, relationships, and attributes. Normalizing is discussed in Normalizing Your Data Model on page 8-33. After you normalize the data model, you can use SQL statements to create a database based on your data model. Chapter 9, Implementing Your Data Model, describes how to create your database and provides the database schema for the telephone-directory example. Each entity you choose is represented as a table in the model. The table stands for the entity as an abstract concept, and each row represents a specic, individual occurrence of the entity. In addition, each attribute of an entity is represented by a column in the table. The following ideas are fundamental to most relational data model methods, including the E-R data model. By following these rules while you design your data model, you will save time and effort when you normalize your model.
8-23
Rules for Dening Tables, Rows, and Columns

You are already familiar with the idea of a table composed of rows and columns. But you must respect the following rules while you dene the tables of a formal data model:
s
Rows must stand alone. Each row of a table is independent and does not depend on any other row of the same table. As a consequence, the order of the rows in a table is not signicant in the model. The model should still be correct even if all the rows of a table are shufed into random order. After the database is implemented, you can tell the database server to store rows in a certain order for the sake of efciency, but that does not affect the model.
Rows must be unique. In every row, some column must contain a unique value. If no single column has this property, the values of some group of columns taken as a whole must be different in every row.
Columns must stand alone. The order of columns within a table has no meaning in the model. The model should still be correct even if the columns are rearranged. After the database is implemented, programs and stored queries that use an asterisk to mean all columns are dependent on the nal order of columns, but that does not affect the model.
Column values must be unitary. A column can contain only single values, never lists or repeating groups. Composite values must be broken into separate columns. For example, if you decide to treat a persons rst and last names as separate values, as shown in the examples in this chapter, they must be in separate columns, not in a single name column.
Each column must have a unique name. Two columns within the same table cannot share the same name. However, you may have columns that contain similar information. For example, the name table in the telephone-directory example contains columns for childrens names. You can name each column, child1, child2, and so on.
8-24
Each column must contain data of a single type. A column must contain information of the same data type. For example, a column identied as an integer must contain only numeric information, not characters from a name.
If your previous experience is only with data organized as arrays or sequential les, these rules might seem unnatural. However, relational database theory shows that you can represent all types of data using only tables, rows, and columns that follow these rules. With a little practice, these rules become automatic.
Placing Constraints on Columns

When you dene your table and columns with the CREATE TABLE statement, you constrain each column. These constraints specify whether you want the column to contain characters or numbers, the form that you want dates to use, and other constraints. A domain describes the constraints on and identies the set of valid values that attributes may assume. The domain characteristics of a column can consist of the following items:
s s s s s s s s s
Data type (INTEGER, CHAR, DATE, and so on) Format (for example, yy/mm/dd) Range (for example, 1,000-5,400) Meaning (for example, personnel number) Allowable values (for example, only grades S or U) Uniqueness Null support Default value Referential constraints
You dene the domain characteristics when you create your tables. Dening domains and creating your tables and database are discussed in Chapter 9, Implementing Your Data Model.
8-25
Determining Keys for Tables

The columns of a table are either key columns or descriptor columns. A key column is one that uniquely identies a particular row in the table. For example, a social-security number is unique for each employee. A descriptor column species the nonunique characteristics of a particular row in the table. For example, two employees may have the same rst name, Sue. The rst name Sue is a nonunique characteristic of an employee. The main types of keys in a table are primary keys and foreign keys. You designate primary and foreign keys when you create your tables. Primary and foreign keys are used to relate tables physically. Your next task is to specify a primary key for each table. That is, you must identify some quantiable characteristic of the table that distinguishes each row from every other.
Primary Keys
The primary key of a table is the column whose values are different in every row. Because they are different, they make each row unique. If no one such column exists, the primary key is a composite of two or more columns whose values, taken together, are different in every row. Every table in the model must have a primary key. This follows automatically from the rule that all rows must be unique. If necessary, the primary key is composed of all the columns taken together. The primary key should be a numeric data type (INT or SMALLINT), SERIAL data type, or a short character string (as used for codes). It is recommended that you avoid using long character strings as primary keys. Null values are never allowed in a primary-key column. Null values are not comparable; that is, they cannot be said to be alike or different. Hence, they cannot make a row unique from other rows. If a column permits null values, it cannot be part of a primary key. Some entities have ready-made primary keys such as catalog codes or identity numbers, which are dened outside the model. These are user-assigned keys.
8-26
Sometimes more than one column or group of columns can be used as the primary key. All columns or groups that qualify to be primary keys are called candidate keys. All candidate keys are worth noting because their property of uniqueness makes them predictable in a SELECT operation. When you select the columns of a candidate key, you know the result can contain no duplicate rows. Sometimes that allows you to predict the uniqueness of the rows returned. It always means that the result of a SELECT operation can be a table in its own right, with the selected candidate key as its primary key.
Composite Keys
Some entities lack features that are reliably unique. Different people can have identical names; different books can have identical titles. You can usually nd a composite of attributes that work as a primary key. For example, it is rare for people to have identical names and identical addresses or for different books to have identical titles, authors, and publication dates.
System-Assigned Keys
A system-assigned primary key is usually preferable to a composite key. A system-assigned key is a number or code that is attached to each instance of an entity when it is rst entered into the database. The easiest systemassigned keys to implement are serial numbers because the database server can generate them automatically. Informix offers the SERIAL data type for serial numbers. However, the people who use the database might not like a plain numeric code. Other codes can be based on actual data; for example, an employee identication code could be based on a persons initials combined with the digits of the date they were hired. In the telephone-directory example, a system-assigned primary key is used for the name table.
8-27
Determining Keys for Tables Foreign Keys (Join Columns)

A foreign key is simply a column or group of columns in one table that contains values that match the primary key in another table. Foreign keys are used to join tables; in fact, most of the join columns referred to earlier in this book are foreign-key columns. Figure 8-16 shows the primary and foreign keys of the customer and order tables from the stores7 database.
customer customer_num order_num orders customer_num
Figure 8-16 Primary and foreign keys in the customer-order relationships
primary key
foreign key
Foreign keys are noted wherever they appear in the model because their presence can restrict your ability to delete rows from tables. Before you can delete a row safely, either you must delete all rows that refer to it through foreign keys or you must dene the relationship using special syntax that allows you to delete rows from primary-key and foreign-key columns with a single delete command. The database server disallows deletes that violate referential integrity. You can always preserve referential integrity by deleting all foreign-key rows before you delete the primary key to which they refer. If you are imposing referential constraints on your database, the database server does not permit you to delete primary keys with matching foreign keys. It also does not permit you to add a foreign-key value that does not reference an existing primary-key value. Referential integrity is discussed in Chapter 4, Modifying Data.
8-28
Determining Keys for Tables Adding Keys to the Telephone-Directory Diagram

The initial choices of primary and foreign keys is shown in Figure 8-17 on page 8-30. This diagram reects some important decisions. For the name table, the primary key rec_num is chosen. Note that the data type for rec_num is SERIAL. The values for rec_num are system-generated. If you look at the other columns (or attributes) in the name table, you see that the data types associated with the columns are mostly character- based. None of these columns alone are good candidates for a primary key. If you combine elements of the table into a composite key, you create an exceedingly cumbersome key. By using a SERIAL data type, you have a key that you can also use to join other tables to the name table. For the voice, fax, and modem tables, the telephone numbers are shown as primary keys. These tables are joined to the name table through the rec_num key. The address table also uses a system-generated primary key, id_num. The address table must have a primary key because the business rules state that an address can exist when no names use it. If the business rules prevent an address from existing unless a name is associated with it, then the address table could be joined to the name table with the foreign key rec_num only.
8-29
Resolving Your Relationships
name rec_num PK lname fname bdate anniv email child1 child2 child3
address id_num PK rec_num FK street city state zipcode
Figure 8-17 Telephonedirectory diagram with primary and foreign keys added
voice vce_num PK rec_num FK vce_type
fax fax_num PK rec_num FK oper_from oper_till
modem mdm_num PK rec_num FK b300 b1200 b2400

The aim of a good data model is to create a structure that provides the database server with quick access. The telephone-directory data model can be further rened by resolving the relationships and normalizing the data model. This section addresses the hows and whys of resolving your relationships. Normalizing your data model is discussed in Normalizing Your Data Model on page 8-33.
Resolving m:n Relationships

Many-to-many (m:n) relationships add complexity and confusion to your model and to the application development process. The key to resolving m:n relationships is to separate the two entities and create two one-to-many (1:n) relationships between them with a third intersect entity. The intersect entity usually contains attributes from both connecting entities.
8-30
To resolve a m:n relationship, analyze your business rules again. Have you accurately diagrammed the relationship? In the telephone-directory example, we have a m:n relationship between the name and fax entities as shown in Figure 8-17 on page 8-30. To resolve the relationship between name and fax, we carefully reviewed the business rules. The business rules say: One person can have zero, one, or many fax numbers; a fax number can be for several people. Based on what we selected earlier as our primary key for the voice entity, a m:n relationship exists. A problem exists in the fax entity because the telephone number, which is designated as the primary key, can appear more than one time in the fax entity; this violates the qualication of a primary key. Remember, the primary key must be unique. This m:n relationship is resolved by adding an intersect entity between name and fax entities. The new intersect entity, faxname, contains two attributes, fax_num and rec_num. The primary key for the entity is a composite of both attributes. Individually, each attribute is a foreign key that references the table from which it came. The relationship between the name and faxname tables is 1:n because one name can be associated with many fax numbers; in the other direction, each faxname combination can be associated with one rec_num. The relationship between the fax and faxname tables is 1:n because each number can be associated with many faxname combinations.
name rec_num PK lname fname bdate anniv email child1 child2 child3
Intersect Entity faxname fax_num PK FK rec_num PK FK
rec_num PK lname fname bdate anniv email child1 child2 child3
Figure 8-18 Resolving a many-to-many (m:n) relationship
fax fax_num PK rec_num FK oper_from oper_till BEFORE
fax fax_num PK oper_from oper_till AFTER
8-31
Resolving Your Relationships Resolving Other Special Relationships

You may encounter other special relationships that can hamper a smooth running database. These relationships are shown in the following list:
s s s
Complex relationships Recursive relationships Redundant relationships
A complex relationship is an association among three or more entities. All the entities must be present for the relationship to exist. To reduce this complexity, reclassify all complex relationships as an entity, related through binary relationships to each of the original entities. A recursive relationship is an association between occurrences of the same entity type. These types of relationships do not occur often. Examples of recursive relationships are bill-of-materials (parts are composed of subparts) and organizational structures (employee manages other employees). See Chapter 5, Programming with SQL, for an extended example of a recursive relationship. You may choose not to resolve recursive relationships. A redundant relationship is when two or more relationships are used to represent the same concept. Redundant relationships add complexity to the data model and may lead a developer to incorrectly place attributes in the model. Redundant relationships may appear as duplicated entries in your entity-relationship diagram. For example, you may have two entities that contain the same attributes. To resolve a redundant relationship, review your data model. Do you have more than one entity that contains the same attributes? You may need to add an entity to the model to resolve the redundancy. The INFORMIX-OnLine Dynamic Server Performance Guide discusses additional topics related to redundancy in a data model.
8-32
Normalizing Your Data Model

The telephone-directory example shown in this chapter appears to be a good model. It could be implemented at this point into a database, but it might present problems later on with application development and datamanipulation operations. Normalization is a formal approach to applying a set of rules used in associating attributes with entities. Normalizing your data model can do the following things:
s s s s s s
Produce greater exibility in your design Ensure that attributes are placed in the proper tables Reduce data redundancy Increase programmer effectiveness Lower application maintenance costs Maximize stability of the data structure
Normalization consists of several steps to reduce the entities to more desirable physical properties. These steps are called normalization rules, also referred to as normal forms. Several normal forms exist; this chapter discusses the rst three normal forms. Each normal form constrains the data to be more organized than the last form. Because of this, you must achieve rst normal form before you can achieve second normal form, and you must achieve second normal form before you can achieve third normal form.
8-33
Normalizing Your Data Model First Normal Form

An entity is in rst normal form if it contains no repeating groups. In relational terms, this means that a table is in rst normal form if it contains no repeating columns. Repeating columns make your data less exible, waste disk space, and make it more difcult to search for data. In the telephonedirectory example, it appears that the name table contains repeating columns, child1, child2, and child3, as shown in Figure 8-19:
name lname fname bdate r anniv email child1 child2 child3
Figure 8-19 Name entity before normalization
repeating columns
Some problems can be noted in the current table. Space is always reserved on the disk for three child records, whether the person has children or not. The maximum number of children that you could record is three; but some of your acquaintances might have four or more children. If you look for a particular child, you would have to search all three columns in every row. You can eliminate the repeating columns and bring the table to rst normal form by separating the table into two tables as shown in Figure 8-20. Put the repeating columns into one of the tables. The association between the two tables is established with a primary and foreign key combination. Because a child cannot exist without an association in the name table, we can reference the name table with a foreign key, rec_num.
name rec_num Primary Key child rec_num Foreign lname fname bdate anniv email
Figure 8-20 First normal form reached for name entity
child_name
8-34
In addition, the modem-name relationship is not at the rst normal form because the columns b300, b1200, and b2400 are considered repeating columns. This relationship is normalized in a similar manner as the name-child relationship, as shown in Figure 8-16 on page 8-28. A b_type attribute is added to the entity which can contain occurrences of b300, b1200, and b2400. Figure 8-16 shows the data model normalized through rst normal form.
name rec_num PK lname fname bdate anniv email child rec_num FK child_name address id_num PK rec_num FK street city state zipcode
Figure 8-21 The data model of a personal telephone directory
voice vce_num PK rec_num vce_type
faxname fax_num PK FK rec_num PK FK
modem mdm_num PK rec_num FK b_type
fax fax_num PK oper_from oper_till
8-35
Normalizing Your Data Model Second Normal Form

An entity is in the second normal form if it is in the rst normal form and all its attributes depend on the whole (primary) key. In relational terms, this means that every column in a table must be functionally dependent on the whole primary key of that table. Functional dependency indicates that a link exists between the values in two different columns. To say that the value of an attribute depends on a column means that, if the value in the column changes, the value of the attribute must also change. The attribute is a function of the column. The following explanations make this more specic:
s
If the table has a one-column primary key, the attribute must depend on that key. If the table has a composite primary key, the attribute must depend on the values in all its columns taken as a whole, not on one or some of them. If the attribute also depends on other columns, these must be columns of a candidate key; that is, columns that are unique in every row.
If you do not convert your model to the second normal form, you risk data redundancy and difculty in changing data. Convert rst normal form tables to second normal form tables by removing columns that are not dependent on the primary key.
Third Normal Form

An entity is in the third normal form if it is in the second normal form and all its attributes are not transitively dependent on the primary key. Transitive dependence means that descriptor key attributes depend not only on the whole primary key but also on other descriptor key attributes that, in turn, depend on the primary key. In SQL terms, the third normal form means that no column within a table is dependent on a descriptor column that, in turn, depends on the primary key. To convert to the third normal form, remove attributes that depend on other descriptor key attributes.
8-36
Normalizing Your Data Model Summary of Normalization Rules

The following normal forms are discussed in this section:
s
First normal form: A table is in the rst normal form if it contains no repeating columns. Second normal form: A table is in the second normal form if it is in the rst normal form and contains only columns that are dependent on the whole (primary) key. Third normal form: A table is in the third normal form if it is in the second normal form and contains only columns that are nontransitively dependent on the primary key.
When you follow these rules, the tables of the model are in what E.F. Codd, the inventor of relational databases, calls the third normal form. When tables are not in the third normal form, either redundant data exists in the model or problems exist when you attempt to update the tables. If you cannot nd a place for an attribute that observes these rules, then you have probably made one of the following errors:
s s s s
The attribute is not well dened. The attribute is derived, not direct. The attribute is really an entity or a relationship. Some entity or relationship is missing from the model.
8-37
Summary
Summary
This chapter summarized and illustrated the following steps of E-R data modeling:
1.
Identify and dene your principal data objects, including the following options:
u u u
Entities Relationships Attributes
2. 3.
Diagram your data objects using the E-R diagram approach. Translate your E-R data objects into relational constructs.
u
Determine the primary and foreign keys for each entity. 1:1 relationships m:n relationships Other special relationships First normal form Second normal form Third normal form
4.
Resolve your relationships, particularly the following relationships:

u u u
5.
Normalize your data model in one of the following forms:

u u u
When the process is done right, you must examine every aspect of the data not once, but several times. If you are interested in learning more about database design, you can attend the Informix course, Relational Database Design. This thorough course presents how to create an E-R data model. If you are interested in pursuing more about database design on your own, the following excellent books are recommended:
s
Database Modeling and Design, The Entity-Relationship Approach by Toby J. Teorey, Morgan Kauffman Publishers, Inc., 1990 Handbook of Relational Database Design by Candace C. Fleming and Barbara von Halle, Addison-Wesley Publishing Company, 1989
8-38
Chapter
Implementing Your Data Model
Dening the Domains . . . . Data Types . . . . . . Choosing a Data Type . Numeric Types . . . Chronological Types. . Character Types . . . Changing the Data Type Null Values . . . . . . Default Values . . . . . Check Constraints . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-3 9-4 9-4 9-8 9-13 9-17 9-22 9-22 9-22 9-23
Creating the Database . . . . . . . . . . . . . . . . . . 9-24 Using CREATE DATABASE . . . . . . . . . . . . . . 9-24 Using CREATE DATABASE with INFORMIX-OnLine Dynamic Server 9-24 Using CREATE DATABASE with Other Informix Database Servers 9-27 Using CREATE TABLE . . . . . . . . . . . . . . . . 9-28 Using Command Scripts . . . . . . . . . . . . . . . 9-30 Capturing the Schema . . . . . . . . . . . . . . . 9-30 Executing the File . . . . . . . . . . . . . . . . 9-31 An Example . . . . . . . . . . . . . . . . . . 9-31 Populating the Tables. . . . . . . . . . . . . . . . . 9-31 Fragmenting Tables and Indexes . . . . . . . . . . . . . . 9-34 9-34 9-35 9-36 9-36 9-37
Creating a Fragmented Table . . . . . . . . . . . . . . . Fragmenting a New Table . . . . . . . . . . . . . . . Creating A Fragmented Table from Nonfragmented Tables. . . . Creating a Table From More Than One Nonfragmented Table . Creating a Fragmented Table from a Single Nonfragmented Table
Modifying a Fragmented Table . . . . . . . . . . . . . . . Modifying Fragmentation Strategies . . . . . . . . . . . Change a Fragmentation Strategy Using the MODIFY Clause . Adding a New Fragment . . . . . . . . . . . . . . Completely Reinitialize a Fragmentation Scheme Using the INIT Clause . . . . . . . . . . . . . . . . . . Dropping A Fragment . . . . . . . . . . . . . . . . Accessing Data Stored in Fragmented Tables Use Primary Keys Instead of Rowids . Rowid in a Fragmented Table . . Creating a Rowid Column . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-37 9-38 9-38 9-39 9-39 9-40 9-41 9-41 9-41 9-42 9-43
9-2
nce a data model is prepared, it must be implemented as a database and tables. This chapter covers the decisions that you must make to implement the model. The rst step in implementation is to complete the data model by dening a domain, or set of data values, for every column. The second step is to implement the model using SQL statements. The rst section of this chapter covers dening domains in detail. The second section shows how you create the database (using the CREATE DATABASE and CREATE TABLE statements) and populate it with data.
Dening the Domains

To complete the data model described in Chapter 8, Building Your Data Model, you must dene a domain for each column. The domain of a column describes the constraints on and identies the set of valid values attributes (or columns) may assume. The purpose of a domain is to guard the semantic integrity of the data in the model; that is, to ensure that it reects reality in a sensible way. If a name can be entered where a telephone number was planned or a fractional number where an integer should be, the integrity of the data model is at risk.
Implementing Your Data Model 9-3
Data Types
You dene a domain by rst dening the constraints that a data value must satisfy before it can be part of the domain. Column domains are specied using the following constraints:
s s s
Data types Default values Check constraints
In addition, referential constraints can be placed on columns by identifying the primary and foreign keys in each table. How to identify these keys was discussed in Chapter 8, Building Your Data Model.
Data Types
The rst constraint on any column is the one that is implicit in the data type for the column. When you choose a data type, you constrain the column so that it contains only values that can be represented by that type. Each data type represents certain kinds of information and not others. The correct data type for a column is the one that represents all the data values that are proper for that column but as few as possible of the values that are not proper for it.
Choosing a Data Type

Every column in a table must have a data type chosen from the types that the database server supports. The choice of data type is important for the following reasons:
s
It establishes the basic domain of the column; that is, the set of valid data items that the column can store. It determines the kinds of operations you can perform on the data. For example, you cannot apply aggregate functions, such as SUM, to columns with a character data type. It determines how much space each data item occupies on disk. This is not important for small tables, but if a table has tens or hundreds of thousands of rows, the difference between a 4-byte and an 8-byte type can be crucial.
9-4
Data Types Using Data Types in Referential Constraints

Almost all data type combinations must match. For example, if a primary key is dened as CHAR, the foreign key must also be dened as CHAR. However, when you specify a SERIAL data type on a primary key in one table, you specify an INTEGER on the foreign key of the relationship. The SERIAL and INTEGER construction is the only data type combination that you can mix in a relationship. The decision tree shown in Figure 9-1 on page 9-6 summarizes the choices among data types. They are explained in the following sections.
Data Types
Figure 9-1 A diagram of the decisions to be made in choosing a data type

Data items purely numeric? no Numbers all integral? no All numbers between -215 and 215-1? no yes SMALLINT yes yes
All numbers between -231 and 231-1? no DECIMAL(p,0) Number of fractional digits is xed? no yes
yes INTEGER
DECIMAL(p,s) yes
At most 8 signicant digits? no
SMALLFLOAT yes
At most 16 signicant digits? no DECIMAL(p)
FLOAT
(1 of 2)
Data Types
Data is chronological? no
yes Span of time or specic point in time? point Precise only to nearest day? no DATETIME span INTERVAL yes DATE
Data contains foreign characters? no
yes
No or little variance in item lengths? no NVARCHAR(m,r) Data is ASCII characters? no No or little variance in item lengths? no yes
yes NCHAR(n)
yes
Lengths under 32,511 bytes? no Length exceeds 255 bytes? BYTE yes TEXT
yes CHAR(n)
no CHARACTER VARYING(m,r) or VARCHAR(m,r)
(2 of 2)
Data Types Numeric Types

Informix database servers support eight numeric data types. Some are best suited for counters and codes, some for engineering quantities, and some for money.
Counters and Codes: INTEGER and SMALLINT

The INTEGER and SMALLINT data types hold small whole numbers. They are suited for columns that contain counts, sequence numbers, numeric identity codes, or any range of whole numbers when you know in advance the maximum and minimum values to be stored. Both types are stored as signed binary integers. INTEGER values have 32 bits and can represent whole numbers from 231 through 2311; that is, from 2,147,483,647 through 2,147,483,647. (The maximum negative number, 2,147,483,248, is reserved and cannot be used.)
SMALLINT values have only 16 bits. They can represent whole numbers from
32,767 through 32,767. (The maximum negative number, -32,768, is reserved and cannot be used.) These data types have the following advantages:
s
They take up little space (2 bytes per value for SMALLINT and 4 bytes per value for INTEGER). Arithmetic expressions such as SUM and MAX as well as sort comparisons can be done very efciently on them.
The disadvantage to using INTEGER and SMALLINT is the limited range of values they can store. The database server does not store a value that exceeds the capacity of an integer. Of course, this is not a problem when you know the maximum and minimum values to be stored.
9-8
Data Types Automatic Sequences: SERIAL

The SERIAL data type is simply INTEGER with a special feature. Whenever a new row is inserted into a table, the database server automatically generates a new value for a SERIAL column. A table can have only one SERIAL column. Because the database server generates them, the serial values in new rows are always different even when multiple users are adding rows at the same time. This is a useful service, because it is quite difcult for an ordinary program to coin unique numeric codes under those conditions. After inserting 231 rows in a table, the database server uses all the positive serial numbers. Depending on your needs, you might be concerned about this because to use all the positive serial numbers, a single application would need to insert a row every second for 68 years, or 68 applications would need to insert a row per second for a year. . However, if it did occur, the database server would continue generating new numbers. It would treat the nextserial quantity as a signed integer. Because it uses only positive values, it would simply wrap around and start generating integer values beginning with 1. The sequence of generated numbers always increases. When rows are deleted from the table, their serial numbers are not reused. This means that rows sorted on a SERIAL column are returned in the order in which they were created. That cannot be said of any other data type. You can specify the initial value in a SERIAL column in the CREATE TABLE statement. This makes it possible to generate different subsequences of system-assigned keys in different tables. The stores7 database uses this technique. In stores7, the customer numbers begin at 101, and the order numbers start at 1001. As long as this small business does not register more than 899 customers, all customer numbers have three digits and order numbers have four.
A SERIAL column is not automatically a unique column. If you want to be
perfectly sure no duplicate serial numbers occur, you must apply a unique constraint (see Using CREATE TABLE on page 9-28). However, if you dene the table using the interactive schema editor in DB-Access or INFORMIX-SQL, it automatically applies a unique constraint to any SERIAL column.
Data Types
The SERIAL data type has the following advantages:

s s
It provides a convenient way to generate system-assigned keys. It produces unique numeric codes even when multiple users are updating the table. Different tables can use different ranges of numbers.
It has the following disadvantages:

s s
Only one SERIAL column is permitted in a table. It can produce only arbitrary numbers (then again, arbitrary numeric codes might not be acceptable to the database users).
Altering the Next SERIAL Number The starting value for a SERIAL column is set when the column is created (see Using CREATE TABLE on page 9-28). You can use the ALTER TABLE statement later to reset the next value, the value that is used for the next-inserted row. You cannot set the next value below the current maximum value in the column because causes the database server to generate duplicate numbers in certain situations. However, you can set the next value to any value higher than the current maximum, thus creating gaps in the sequence.
Approximate Numbers: FLOAT and SMALLFLOAT

In scientic, engineering, and statistical applications, numbers are often known to only a few digits of accuracy, and the magnitude of a number is as important as its exact digits. The oating-point data types are designed for these applications. They can represent any numerical quantity, fractional or whole, over a wide range of magnitudes from the cosmic to the microscopic. For example, they can easily represent both the average distance from the Earth to the Sun (1.5 109 meters) or Plancks constant (6.625 10-27). Their only restriction is their limited precision. Floating-point numbers retain only the most signicant digits of their value. If a value has no more digits than a oating-point number can store, the value is stored exactly. If it has more digits, it is stored in approximate form, with its least-signicant digits treated as zeros.
9-10
Data Types
This lack of exactitude is ne for many uses, but you should never use a oating-point data type to record money or any other quantity for which it is an error to change the least signicant digits to zero. Two sizes of oating-point data types exist. The FLOAT type is a double-precision, binary oating-point number as implemented in the C language on your computer. One usually takes up 8 bytes. The SMALLFLOAT (also known as REAL) type is a single-precision, binary oating-point number that usually takes up 4 bytes. The main difference between the two data types is their precision. A FLOAT column retains about 16 digits of its values; a SMALLFLOAT column retains only about 8 digits. Floating-point numbers have the following advantages:
s
They store very large and very small numbers, including fractional ones. They represent numbers compactly in 4 or 8 bytes. Arithmetic functions such as AVG, MIN, and sort comparisons, are efcient on these data types.
s s
The main disadvantage of oating-point numbers is that digits outside their range of precision are treated as zeros.
Adjustable-Precision Floating Point: DECIMAL(p)

The DECIMAL(p) data type is a oating-point type similar to FLOAT and SMALLFLOAT. The important difference is that you specify how many significant digits it retains. The precision you write as p may range from 1 to 32, from fewer than SMALLFLOAT up to twice the precision of FLOAT. The magnitude of a DECIMAL(p) number ranges from 10-130 to 10124. It is easy to be confused about decimal data types. The one under discussion is DECIMAL(p); that is, DECIMAL with only a precision specied. The size of DECIMAL(p) numbers depends on their precision; they occupy 1+p/2 bytes (rounded up to a whole number, if necessary).
DECIMAL(p) has the following advantages over FLOAT:
s
Precision can be set to suit the application, from highly approximate to highly precise. Numbers with as many as 32 digits can be represented exactly.
Data Types
s s
Storage is used in proportion to the precision of the number. Every Informix database server supports the same precision and range of magnitudes, regardless of the host operating system.
The DECIMAL(p) data type has the following disadvantages:

s
Arithmetic and sorting are somewhat slower than on FLOAT numbers. Many programming languages do not support the DECIMAL(p) data format the way they support FLOAT and INTEGER. When a program extracts a DECIMAL(p) value from the database, it may have to convert the value to another format for processing. (However, INFORMIX-4GL programs can use DECIMAL(p) values directly.)
Fixed-Point Numbers: DECIMAL and MONEY

Most commercial applications need to store numbers that have xed numbers of digits on the right and left of the decimal point. Amounts of money are the most common examples. Amounts in U.S. and other currencies are written with two digits to the right of the decimal point. Normally, you also know the number of digits needed on the left, depending on whose transactions are recordedperhaps 5 digits for a personal budget, 7 for a small business, and 12 or 13 for a national budget. These numbers are xed-point numbers because the decimal point is xed at a specic place, regardless of the value of the number. The DECIMAL(p,s) data type is designed to hold them. When you specify a column of this type, you write its precision (p) as the total number of digits it can store, from 1 to 32. You write its scale (s) as the number of those digits that fall to the right of the decimal point. (The relation between precision and scale is shown in Figure 9-2.) Scale can be zero, meaning it stores only whole numbers. When this is done, DECIMAL(p,s) provides a way of storing integers of up to 32 digits.
precision: 8 digits
DECIMAL(8,3)
31964.535
scale: 3 digits
Figure 9-2 The relation between precision and scale in a xedpoint number
9-12
Data Types
As with the DECIMAL(p) data type, DECIMAL(p,s) takes up space in proportion to its precision. One value occupies 1+p/2 bytes, rounded up to a whole number of bytes. The MONEY type is identical to DECIMAL(p,s), but with one extra feature. Whenever the database server converts a MONEY value to characters for display, it automatically includes a currency symbol. The advantages of DECIMAL(p,s) over INTEGER and FLOAT are that much greater precision is available (up to 32 digits as compared with 10 for INTEGER and 16 for FLOAT), and both the precision and the amount of storage required can be adjusted to suit the application. The disadvantages are that arithmetic is less efcient and that many programming languages do not support numbers in this form. Therefore, when a program extracts a number, it usually must convert it to another numeric form for processing. (However, INFORMIX-4GL programs can use DECIMAL(p,s) and MONEY values directly.) Whose Money? Choosing a Currency Format Each nation has its own way of punctuating amounts of money. When an Informix database server displays a MONEY value, it refers to a currency format dened to the operating system, usually in a variable named DBMONEY. A currency symbol can precede or follow the amount, and the decimal delimiter can be set to a period, a comma, or another character. When in NLS mode, you can set the LC_MONETARY environment variable to specify a foreign currency symbol and format. For details, see Chapter 4 of the Informix Guide to SQL: Reference.
Chronological Types
Informix database servers support three data types for recording time. The DATE data type stores a calendar date. DATETIME records a point in time to any degree of precision from a year to a fraction of a second. The INTERVAL data type stores a span of time; that is, a duration.
Data Types Calendar Dates: DATE

The DATE data type stores a calendar date. A DATE value is actually a signed integer whose contents are interpreted as a count of full days since midnight on December 31, 1899. Most often it holds a positive count of days into the current century. The DATE format has ample precision to carry dates into the far future (58,000 centuries). Negative DATE values are interpreted as counts of days prior to the epoch date; that is, a DATE of -1 represents the day December 30, 1899. Because DATE values are integers, Informix database servers permit them to be used in arithmetic expressions. For example, you can take the average of a DATE column, or you can add 7 or 365 to a DATE column. In addition, a rich set of functions exist specically for manipulating DATE values. (See Chapter 1 of the Informix Guide to SQL: Syntax.) The DATE data type is compact at 4 bytes per item. Arithmetic functions and comparisons execute quickly on a DATE column. M/D/Y? D-M-Y? Choosing a Date Format You can punctuate and order the components of a date in many ways. When an Informix database server displays a DATE value, it refers to a format dened to the operating system, usually in a variable named DBDATE. The numbers for day, month, and year can be shown in any order, separated by a chosen delimiter. For more information, see Chapter 4 of the Informix Guide to SQL: Reference.
Exact Points in Time: DATETIME

The DATETIME data type stores any moment in time in the era beginning 1 A.D. In fact, DATETIME is really a family of 28 data types, each with a different precision. When you dene a DATETIME column, you specify its precision. It may contain any sequence from the list year, month, day, hour, minute, second, and fraction. Thus, you can dene a DATETIME column that stores only a year, only a month and day, a date and time that is exact to the hour, or even to the millisecond. The size of a DATETIME value ranges from 2 to 11 bytes depending on its precision, as shown in Figure 9-3 on page 9-15.
9-14
Data Types
The advantage of DATETIME is that it can store dates more precisely than to the nearest day, and it can store time values. Its sole disadvantage is an inexible display format, but this can be circumvented (see Forcing the Format of a DATETIME or INTERVAL Value on page 9-16).
Precision year to year year to month year to day year to hour year to minute year to second year to fraction (f) month to month month to day month to hour month to minute month to second month to fraction(f) day to day Size* 3 4 5 6 7 8 8+f/2 2 3 4 5 6 6+f/2 2 Precision Size* day to hour 3 day to minute 4 day to second 5 day to fraction(f) 5+f/2 hour to hour 2 hour to minute 3 hour to second 4 hour to fraction(f) 4+f/2 minute to minute 2 minute to second 3 minute to fraction(f) 3+f/2 second to second 2 second to fraction(f) 2+f/2 fraction to fraction(f) 1+f/2
Figure 9-3 All possible precisions of the DATETIME data type, with their sizes in bytes
* When f is odd, round the size to the next full byte.
Durations: INTERVAL
The INTERVAL data type stores a duration, that is, a length of time. The difference between two DATETIME values is an INTERVAL, which represents the span of time that separates them. The following examples might help to clarify the differences:
s
An employee began working on January 21, 1994 (either a DATE or a DATETIME). She has worked for 254 days (an INTERVAL, the difference between the TODAY function and the starting DATE or DATETIME). She begins work each day at 0900 hours (a DATETIME). She works 8 hours (an INTERVAL) with 45 minutes for lunch (another INTERVAL). Her quitting time is 1745 hours (the sum of the DATETIME when she begins work and the two INTERVALs).
s s
Data Types
As with DATETIME, INTERVAL is a family of types with different precisions. An INTERVAL can represent a count of years and months; or it can represent a count of days, hours, minutes, seconds, or fractions of seconds; 18 possible precisions in all. The size of an INTERVAL value ranges from 2 to 12 bytes, depending on the formulas shown in Figure 9-4.
Precision year(p) to year year(p) to month month(p) to month day(p) to day day(p) to hour day(p) to minute day(p) to second day(p) to fraction(f) hour(p) to hour Size* 1+p/2 2+p/2 1+p/2 1+p/2 2+p/2 3+p/2 4+p/2 5+(p+f)/2 1+p/2 Precision hour(p) to minute hour(p) to second hour(p) to fraction(f) minute(p) to minute minute(p) to second minute(p) to fraction(f) second(p) to second second(p) to fraction(f) fraction to fraction(f) Size* 2+p/2 3+p/2 4+(p+f)/2 1+p/2 2+p/2 3+(p+f)/2 1+p/2 2+(p+f)/2 1+f/2
Figure 9-4 All possible precisions of the INTERVAL data type, with their sizes in bytes
* Round a fractional size to the next full byte.
INTERVAL values can be negative as well as positive. You can add or subtract
them, and you can scale them by multiplying or dividing by a number. This is not true of either DATE or DATETIME. It is reasonable to ask, What is onehalf the number of days until April 23? but it is not reasonable to ask, What is one-half of April 23? Forcing the Format of a DATETIME or INTERVAL Value The database server always displays the components of an INTERVAL or DATETIME value in the order year-month-day hour:minute:second.fraction. It does not refer to the date format dened to the operating system, as it does when formatting a DATE. You can write a SELECT statement that displays the date part of a DATETIME value in the system-dened format. The trick is to isolate the component elds using the EXTEND function and pass them through the MDY() function, which converts them to a DATE. The following code shows a partial example:
SELECT ... MDY ( EXTEND (DATE_RECEIVED, MONTH TO MONTH), EXTEND (DATE_RECEIVED, DAY TO DAY), EXTEND (DATE_RECEIVED, YEAR TO YEAR) ) FROM RECEIPTS ...
9-16
Data Types
When you are designing a report using INFORMIX-4GL or INFORMIX-SQL, you have the greater exibility of the PRINT statement. Select each component of a DATETIME or INTERVAL value as an expression using EXTEND. Give each expression an alias for convenience, as shown in the following partial SELECT statement:
SELECT ... EXTEND (START_TIME, HOUR TO HOUR) H, EXTEND (START_TIME, MINUTE TO MINUTE) M, ...
Then, in the report, combine the components in a PRINT expression with the desired punctuation, as shown in the following example:
PRINT 'Start work at ', H USING '&&', M USING '&&', 'hours.' Start work at 0800 hours.
Character Types
All Informix database servers support the CHAR(n) data type. When NLS has been enabled, the Informix database servers support the NCHAR(n) data type. INFORMIX-OnLine Dynamic Server also supports other special use character data types.
Character Data: CHAR(n) and NCHAR(n)

The CHAR(n) data type contains a sequence of n ASCII characters. The length n ranges from 1 to 32,767. (If you are using the INFORMIX-SE database server, the maximum length is 32,511.) In NLS mode, the NCHAR(n) data type contains a sequence of n native characters with the same length range as CHAR. Whenever a CHAR(n) or NCHAR(n) value is retrieved or stored, exactly n bytes are transferred. If an inserted value is short, it is extended with spaces to make up n bytes. A value longer than n is truncated. No provision exists for variable-length data in this format. A CHAR(n) or NCHAR(n) value can include tabs and spaces but normally contains no other nonprinting characters. When rows are inserted using INSERT or UPDATE, or when rows are loaded with a utility program, no means exists for entering nonprintable characters. However, when rows are created by a program using embedded SQL, the program can insert any character except the null (binary zero) character. It is not a good idea to store nonprintable characters in a character column because standard programs and utilities do not expect them.
Data Types
The advantage of the CHAR(n) or NCHAR(n) data type is that it is available on all database servers. The only disadvantage of CHAR(n) or NCHAR(n) is that its length is xed. When the length of data values varies widely from row to row, space is wasted. NCHAR(n) is available on all database servers when NLS has been enabled.
Variable-Length Strings: CHARACTER VARYING(m,r), VARCHAR(m,r), and NVARCHAR(m,r)

Tip: The data type CHARACTER VARYING (m,r) is ANSI-compliant. V ARCHAR(m,r) is an Informix data type.
Often the items in a character column have different lengths; that is, many have an average length and only a few have the maximum length. The CHARACTER VARYING(m,r) or VARCHAR(m,r) data type (or NVARCHAR(m,r) when NLS has been enabled) is designed to save disk space when storing such data. A column dened as CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) is used just like one dened as CHAR(n). When you dene a CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) column, you specify m as the maximum length of a data item. Only the actual contents of each item are stored on disk, with a 1-byte length eld. The limit on m is 255; that is, a CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) value can store as many as 255 characters. If the column is indexed, the limit on m is 254. The second parameter, r, is an optional reserve length that sets a lower limit on the length of an item as stored on disk. When an item is shorter than r, r bytes are nevertheless allocated to hold it. The purpose is to save time when rows are updated. (See Variable-Length Execution Time on page 9-19.) The advantages of the CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) data type over the CHAR(n) or NCHAR(m,r) type are found in the following list:
s
It conserves disk space when the lengths of data items vary widely or when only a few items are longer than average. Queries on the more compact tables can be faster.
9-18
Data Types
The following list describes its disadvantages:

s s s
It does not allow lengths that exceed 255 characters. Updates of a table can be slower in some circumstances. It is not available with all Informix database servers.
Variable-Length Execution Time

When the CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) data type is used, the rows of a table have varying lengths instead of xed lengths. This has mixed effects on the speed of database operations. Because more rows t in a disk page, the database server can search the table using fewer disk operations than if the rows were of xed length. As a result, queries can execute more quickly. Insert and delete operations can be a little quicker for the same reason. When you update a row, the amount of work the database server must do depends on the length of the new row as compared with the old one. If the new row is the same size or shorter, execution time is not signicantly different than it is with xed-length rows. But if the new row is longer than the old one, the database server might have to perform several times as many disk operations. Thus, updates of a table that uses CHARACTER VARYING(m,r), VARCHAR(m,r), or NVARCHAR(m,r) data can sometimes be slower than updates of a xed-length eld. You can mitigate this effect by specifying r as a size that covers a high proportion of the data items. Then, most rows use the reserve length; only a little space is wasted in padding, and updates are only slow when a normal value is replaced with one of the rare, longer ones.
Data Types Large Character Objects: TEXT

The TEXT data type stores a block of text. It is designed to store self-contained documents: business forms, program source or data les, or memos. Although you can store any data in a TEXT item, Informix tools expect that a TEXT item is printable, so this data type should be restricted to printable ASCII text.
TEXT values are not stored with the rows of which they are a part. They are
allocated in whole disk pages, usually areas away from rows. (See the INFORMIX-OnLine Dynamic Server Administrators Guide.) The advantage of the TEXT data type over CHAR(n) and VARCHAR(m,r) is that the size of a TEXT data item has no limit except the capacity of disk storage to hold it. The disadvantages of the TEXT data type are found in the following list:
s s
It is allocated in whole disk pages; a short item wastes space. Restrictions apply on how you can use a TEXT column in an SQL statement. (See How Blobs Are Used.) It is not available with all Informix database servers.
You can display TEXT values in reports generated with INFORMIX-4GL programs or the ACE report writer. You can display TEXT values on a screen and edit them using screen forms generated with INFORMIX-4GL programs or with the PERFORM screen-form processor.
How Blobs Are Used

Collectively, columns of type TEXT and BYTE are called binary large objects (blobs). The database server simply stores and retrieves them. Normally, blob values are fetched and stored by programs written using INFORMIX-4GL, NewEra, or a language that supports embedded SQL, such as INFORMIX-ESQL/C. In such a program you can fetch, insert, or update a blob value in a manner similar to the way you read or write a sequential le.
9-20
Data Types
In any SQL statement, interactive or programmed, a blob column cannot be used in the following ways:
s s s s
In arithmetic or Boolean expressions In a GROUP BY or ORDER BY clause In a UNIQUE test For indexing, either by itself or as part of a composite index
In a SELECT statement entered interactively, or in a form or report, a blob can only perform the following functions:
s s s
Be selected by name, optionally with a subscript to extract part of it Have its length returned by selecting LENGTH(column) Be tested with the IS [NOT] NULL predicate
In an interactive INSERT statement, you can use the VALUES clause to insert a blob value, but the only value you can give that column is null. However, you can use the SELECT form of the INSERT statement to copy a blob value from another table. In an interactive UPDATE statement, you can update a blob column to null or to a subquery returning a blob column.
Binary Objects: BYTE

The BYTE data type is designed to hold any data a program can generate: graphic images, program object les, and documents saved by any word processor or spreadsheet. The database server permits any kind of data of any length in a BYTE column. As with TEXT, BYTE data items are stored in whole disk pages in separate disk areas from normal row data. The advantage of THE BYTE data type, as opposed to TEXT or CHAR(n), is that it accepts any data. Its disadvantages are the same as those of the TEXT data type.
Null Values Changing the Data Type

You can use the ALTER TABLE statement to change the data type assigned to a column after the table is built. Although this is sometimes necessary, you should avoid doing it for the following reasons:
s
To change a data type, the database server must copy and rebuild the table. For large tables, that can take a lot of time and disk space. Some data-type changes can cause a loss of information. For example, when you change a column from a longer to a shorter character type, long values are truncated; when you change to a less-precise numeric type, low-order digits are truncated. Existing programs, forms, reports, and stored queries might also have to be changed.
Null Values
Columns in a table may be designated as containing null values. A null value means that the value for the column may be unknown or not applicable. For example, in the telephone-directory example in Chapter 8, the anniv column of the name table may contain null values; if you do not know the persons anniversary, you do not specify it. Be careful not to confuse null value with zero or blank value.
Default Values
A default value is the value inserted into a column when an explicit value is not specied in an INSERT statement. A default value can be a literal character string dened by you or one of the following SQL null, constant expressions:
s s s s
USER CURRENT TODAY DBSERVERNAME
9-22
Check Constraints
Not all columns need default values, but as you work with your data model you may discover instances where the use of a default value saves data-entry time or prevents data-entry error. For example, the telephone-directory model has a State column: While looking at the data for this column, you discover that more than 50 percent of the addresses list California as the state. To save time, you specify the string CA as the default value for the State column.
Check Constraints
Check constraints specify a condition or requirement on a data value before data can be assigned to a column during an INSERT or UPDATE statement. If a row evaluates to false for any of the check constraints dened on a table during an insert or update, the database server returns an error. You dene a constraint using the CREATE TABLE or ALTER TABLE statements. For example, the following requirement constrains the values of an integer domain to a certain range:
Customer_Number >= 50000 AND Customer_Number <= 99999
You can express constraints on character-based domains using the MATCHES predicate and the regular-expression syntax it supports. For example, the following constraint restricts a Telephone domain to the form of a U.S. local telephone number:
vce_num MATCHES '[2-9][2-9][0-9]-[0-9][0-9][0-9][0-9]'
For additional information about check constraints, see the CREATE TABLE and ALTER TABLE statements in the Informix Guide to SQL: Syntax.
Creating the Database
Creating the Database

Now you are ready to create the data model as tables in a database. You do this with the CREATE DATABASE, CREATE TABLE, and CREATE INDEX statements. The syntax of these statements is shown in detail in the Informix Guide to SQL: Syntax. This section discusses the use of CREATE DATABASE and CREATE TABLE in implementing a data model. The use of CREATE INDEX is covered in Chapter 10, Granting and Limiting Access to Your Database. Keep in mind that the telephone-directory data model is used for illustrative purposes only. For the sake of the example, we translate it into SQL statements. You might have to create the same database model more than once. However, the statements that create the model can be stored and executed automatically. See Using Command Scripts on page 9-30 for more information. When the tables exist, you must populate them with rows of data. You can do this manually, with a utility program, or with custom programming.
Using CREATE DATABASE

A database is a container that holds all the parts that go in to a data model. These parts include not only the tables but also views, indexes, synonyms, and other objects associated with the database. You must create a database before you can create anything else. Besides creating the database, the CREATE DATABASE statement establishes the kind of transaction logging to be used. Transaction logging is discussed in Chapter 4, Modifying Data. The OnLine database server differs from other database servers in the way that it creates databases and tables: OnLine is discussed rst.
Using CREATE DATABASE with INFORMIX-OnLine Dynamic Server

When the OnLine database server creates a database, it sets up records that show the existence of the database and its mode of logging. It manages disk space directly, so these records are not visible to operating system commands.
9-24
Using CREATE DATABASE Avoiding Name Conicts

Normally, only one copy of OnLine is running on a computer, and it manages the databases that belong to all users of that computer. It keeps only one list of database names. The name of your database must be different from that of any other database managed by that database server. (It is possible to run more than one copy of the database server. This is sometimes done, for example, to create a safe environment for testing apart from the operational data. In that case, you must be sure you are using the correct database server when you create the database, and again when you access it later.)
Selecting a Dbspace
OnLine offers you the option of creating the database in a particular dbspace. A dbspace is a named area of disk storage. Ask your OnLine administrator whether you should use a particular dbspace. The administrator can put a database in a dbspace to isolate it from other databases or to locate it on a particular disk device. (The INFORMIX-OnLine Dynamic Server Administrators Guide discusses dbspaces and their relationship to disk devices.) Some dbspaces are mirrored (duplicated on two disk devices for high reliability); your database can be put in a mirrored dbspace if its contents are of exceptional importance.
Using CREATE DATABASE Choosing the Type of Logging

OnLine offers the following choices for transaction logging:
s
No logging at all. This choice is not recommended; if the database is lost to a hardware failure, all data alterations since the last archive are lost.
CREATE DATABASE db_with_no_log
When you do not choose logging, BEGIN WORK and other SQL statements related to transaction processing are not permitted in the database. This affects the logic of programs that use the database.
s
Regular (unbuffered) logging. This is the best choice for most databases. In the event of a failure, only uncommitted transactions are lost.
CREATE DATABASE a_logged_db WITH LOG
Buffered logging. If the database is lost, a few or possibly none of the most recent alterations are lost. In return for this small risk, performance during alterations is improves slightly.
CREATE DATABASE buf_log_db WITH BUFFERED LOG
Buffered logging is best for databases that are updated frequently (so that speed of updating is important), but the updates can be recreated from other data in the event of a crash. You can use the SET LOG statement to alternate between buffered and regular logging.
s
ANSI-compliant logging. This is the same as regular logging, but the ANSI rules for transaction processing are also enforced. (See the discussion of ANSI-compliant databases in Chapter 1 of the Informix
Guide to SQL: Reference.)

CREATE DATABASE std_rules_db WITH LOG MODE ANSI
The design of ANSI SQL prohibits the use of buffered logging. The OnLine administrator can turn transaction logging on and off later. For example, it can be turned off before inserting a large number of new rows.
9-26
Using CREATE DATABASE Using CREATE DATABASE with Other Informix Database Servers
Other Informix database servers create a database as a set of one or more les managed by the operating system. For example, under the UNIX operating system, a database is a small group of les in a directory whose name is the database name. (See the manual for your database server for details on how it uses les.) This means that the rules for database names are the same as the rules the operating system has for le names.
Choosing the Type of Logging

Other database servers offer the following three choices of logging:
s
No logging at all. This choice is not recommended; if the database is lost to a hardware failure, all data alterations since the last archive are lost.
CREATE DATABASE not_logged_db
When you do not choose logging, BEGIN WORK and other SQL statements related to transaction processing are not permitted in the database. This affects the logic of programs that use the database.
s
Regular logging. This is the best choice for most databases. If the database is lost, only the alteration in progress at the time of failure is lost.
CREATE DATABASE a_logged_db WITH LOG IN '/logs/a_log_file'
You must specify a le to contain the transaction log. (The form of the le name depends on the rules of your operating system.) This le grows whenever the database is altered. Whenever the database les are archived, you should set the log le back to an empty condition so it reects only transactions following the latest archive.
s
ANSI-compliant logging. This is the same as regular logging, but the ANSI rules for transaction processing are also enforced. (See the discussion of ANSI-compliant databases in Chapter 1 of the Informix
Guide to SQL: Reference.)

CREATE DATABASE std_rules_db WITH LOG IN '/logs/a_log_file' MODE ANSI
You can add a transaction log to a nonlogged database later using the START
DATABASE statement.
Using CREATE TABLE
Using CREATE TABLE

Use the CREATE TABLE statement to create each table you designed in the data model. This statement has a complicated form, but it is basically a list of the columns of the table. For each column, you supply the following information:
s s s
The name of the column The data type (from the domain list you made) If the column (or columns) is a primary key, the PRIMARY KEY constraint If the column (or columns) is a foreign key, the FOREIGN KEY constraint If the column is not a primary key and should not allow nulls, the NOT NULL constraint If the column is not a primary key and should not allow duplicates, the UNIQUE constraint If the column has a default value, the DEFAULT constraint If the column has a check constraint, the CHECK constraint
s s
In short, the CREATE TABLE statement is an image in words of the table as you drew it in the data model diagram. Figure 9-5 on page 9-29 shows the statements for the telephone-directory model whose diagram is shown in Figure 8-16 on page 8-28.
9-28
Using CREATE TABLE
CREATE TABLE name ( rec_num SERIAL PRIMARY KEY, lname CHAR(20), fname CHAR(20), bdate DATE, anniv DATE, email VARCHAR(25) ); CREATE TABLE child ( child CHAR(20), rec_num INT, FOREIGN KEY (rec_num) REFERENCES NAME (rec_num) ); CREATE TABLE address ( id_num SERIAL PRIMARY KEY, rec_num INT, street VARCHAR (50,20), city VARCHAR (40,10), state CHAR(5) DEFAULT CA, zipcode CHAR(10), FOREIGN KEY (rec_num) REFERENCES name (rec_num) ); CREATE TABLE voice ( vce_num CHAR(13) PRIMARY KEY, vce_type CHAR(10), rec_num INT, FOREIGN KEY (rec_num) REFERENCES name (rec_num) ); CREATE TABLE fax ( fax_num CHAR(13), oper_from DATETIME HOUR TO MINUTE, oper_till DATETIME HOUR TO MINUTE, PRIMARY KEY (fax_num) );
Figure 9-5 The CREATE TABLE statements for the telephone-directory data model
(1 of 2)
Using Command Scripts
CREATE TABLE faxname ( fax_num CHAR(13), rec_num INT, PRIMARY KEY (fax_num, rec_num), FOREIGN KEY (fax_num) REFERENCES fax (fax_num), FOREIGN KEY (rec_num) REFERENCES name (rec_num) ); CREATE TABLE modem ( mdm_num CHAR(13) PRIMARY KEY, rec_num INT, b_type CHAR(5), FOREIGN KEY (rec_num) REFERENCES name (rec_num) );
(2 of 2)
Using Command Scripts

You can create the database and tables by entering the statements interactively. But what if you have to do it again or several more times? You might have to do it again to make a production version after a test version is satisfactory. You might have to implement the same data model on several computers . To save time and reduce the chance of errors, you can put all the commands to create a database in a le and execute them automatically.
Capturing the Schema

You can write the statements to implement your model into a le. However, you can also have a program do it for you. See Chapter 5 of the Informix Guide to SQL: Reference. It documents the dbschema utility, a program that examines the contents of a database and generates all the SQL statements required to re-create it. You can build the rst version of your database interactively, making changes until it is exactly as you want it. Then you can use dbschema to generate the SQL statements necessary to duplicate it.
9-30
Populating the Tables Executing the File

DB-Access or INFORMIX-SQL, the programs you use to enter SQL statements interactively, can be driven from a le of commands. The use of these products is covered in the DB-Access User Manual or the INFORMIX-SQL User Guide. You can start DB-Access or INFORMIX-SQL and have them read and execute a le of commands prepared by you or by dbschema.
An Example
Most Informix database server products come with a demonstration database called stores7 (the one used for most of the examples in this book). The stores7 database is delivered as an operating system command script that calls Informix products to build the database. You can copy this command script and use it as the basis for automating your own data model.
Populating the Tables

For your initial tests, it is easiest to populate the tables interactively by typing INSERT statements in DB-Access or INFORMIX-SQL. As shown in the following example, to insert a row into the manufact table of the stores7 database in DB-Access, enter the following command:
INSERT INTO manufact VALUES ('MKL', 'Martin', 15)
If you are preparing an application program in NewEra, INFORMIX-4GL, or another language, you can use the program to enter rows. Often, the initial rows of a large table can be derived from data held in tables in another database or in operating system les. You can move the data into your new database in a bulk operation. If the data is in another Informix database, you can retrieve it in several ways. If you are using INFORMIX-OnLine Dynamic Server, you can simply select the data you want from the other database on another database server as part of an INSERT statement in your database. As shown in the following example, you could select information from the items table in the stores7 database to insert into a new table:
INSERT INTO newtable SELECT item_num, order_num, quantity, stock_num, manu_code, total_price FROM stores7@otherserver:items
If you are using INFORMIX-SE, you can select the data you want from one database and insert it into another database as long as the databases are on the same database server. As shown in the following example, you could select information from the catalog table in the stores7 database to insert into a new table by using a temporary table:
CONNECT TO 'sharky/db1'; SELECT item_num, stock_num, manu_code FROM items INTO TEMP temptable; DISCONNECT; CONNECT TO 'sharky/db2'; SELECT * from temptable INTO TEMP newsetable;
If you want to select data from another database server in INFORMIX-SE, you must export the data to a le. You can use the UNLOAD statement in DB-Access, INFORMIX-SQL, NewEra, or INFORMIX-4GL; or you can write a report in ACE or INFORMIX-4GL and direct the output to a le. When the source is another kind of le or database, you must nd a way to convert it into a at ASCII le; that is, a le of printable data in which each line represents the contents of one table row. After you have the data in a le, you can load it into a table using the dbload utility. Read about dbload in Chapter 5 of the Informix Guide to SQL: Reference. The LOAD statement in DB-Access, INFORMIX-SQL, INFORMIX-4GL, or NewEra can also load rows from a at ASCII le. See Chapter 1 of the Informix Guide to SQL: Syntax for information about the LOAD and UNLOAD statements.
9-32
Inserting hundreds or thousands of rows goes much faster if you turn off transaction logging. No point exists in logging these insertions because, in the event of a failure, you can easily re-create the lost work. The following list contains the steps of a large bulk-load operation:
s
If any chance exists that other users are using the database, exclude them with the DATABASE EXCLUSIVE statement. If you are using INFORMIX-OnLine Dynamic Server, ask the administrator to turn off logging for the database. The existing logs can be used to recover the database to its present state, and the bulk insertion can be run again to recover those rows if they are lost.
Perform the statements or run the utilities that load the tables with data. Archive the newly loaded database. If you are using INFORMIX-OnLine Dynamic Server, either ask the administrator to perform a full or incremental archive, or use the onunload utility to make a binary copy of your database only. If you are using other database servers, use operating system commands to back up the les that represent the database.
Restore transaction logging and release the exclusive lock on the database.
You can enclose the steps of populating a database in a script of operating system commands. You can automate the INFORMIX-OnLine Dynamic Server administrator commands by invoking the command-line equivalents to ONMonitor.
Fragmenting Tables and Indexes
Fragmenting Tables and Indexes

This section on fragmentation explains how to create and manage fragmented tables using SQL statements. It covers the following topics:
s s
How to create and maintain fragmented tables and indexes How to access data stored in fragmented tables
Before reading this section, you should familiarize yourself with the terms and concepts related to fragmentation and PDQ that are contained in the INFORMIX-OnLine Dynamic Server Administrators Guide.
Creating a Fragmented Table

You can fragment a table at the same time you create it, or you can fragment existing nonfragmented tables. An overview of both alternatives is given in the following sections. For the complete syntax of the SQL statements that you use to create fragmented tables, see Chapter 1 of the Informix Guide to SQL: Syntax. Before you create a fragmented table, you must decide on an appropriate distribution scheme for your tables. See the INFORMIX-OnLine Dynamic Server Administrators Guide for advice on choosing a distribution scheme that meets your needs.
9-34
Fragmenting a New Table
Fragmenting a New Table

To create a fragmented table, use the FRAGMENT BY clause of the CREATE TABLE statement. Suppose that you wish to create a fragmented table similar to the stores7 table, orders. You decide on a round-robin distribution scheme with three fragments. Consult with the OnLine administrator to set up three dbspaces, one for each of the fragments: dbspace1, dbspace2, and dbspace3. To create the fragmented table, execute the following SQL statement:
CREATE TABLE my_orders ( order_num SERIAL(1001), order_date DATE, customer_num INT, ship_instruct CHAR(40), backlog CHAR(1), po_num CHAR(10), ship_date DATE, ship_weight DECIMAL(8,2), ship_charge MONEY(6), paid_date DATE, PRIMARY KEY (order_num), FOREIGN KEY (customer_num) REFERENCES customer(customer_num)) FRAGMENT BY ROUND ROBIN IN dbspace1,dbspace2,dbspace3
If you decide instead to create the table using an expression-based distribution scheme, you can use the FRAGMENT BY EXPRESSION clause of CREATE TABLE. Suppose your my_orders table has 30,000 rows, and that you wish to distribute rows evenly across three fragments stored in dbspace1, dbspace2, and dbspace3. You decide to use the column order_num to dene the expression fragments. You can dene the expression as shown in the following example:
CREATE TABLE my_orders (order_num serial, ...) FRAGMENT BY EXPRESSION order_num < 10000 IN dbspace1, order_num < 20000 IN dbspace2, order_num >= 20000 IN dbspace3
Creating A Fragmented Table from Nonfragmented Tables
Creating A Fragmented Table from Nonfragmented Tables

You might need to convert nonfragmented tables into fragmented tables in the following circumstances:
s
You have an application-implemented version of table fragmentation. In this case, it is likely that you will want to convert several small tables into one large fragmented table. The following section tells you how to proceed when this is the case.
You have an existing large table that you want to fragment. Follow the instructions in the section Creating a Fragmented Table from a Single Nonfragmented Table on page 9-37.
Remember that before you perform the conversion, you must set up an appropriate number of dbspaces to contain the newly created fragmented tables.
Creating a Table From More Than One Nonfragmented Table

You can combine two or more nonfragmented tables into a single fragmented table. The nonfragmented tables must have identical table structures and must be stored in separate dbspaces. To combine the nonfragmented tables, use the ATTACH clause of the ALTER FRAGMENT statement. For example, suppose that you have three nonfragmented tables, account1, account2, and account3, and that you store the tables in the dbspaces dbspace1, dbspace2, and dbspace3, respectively. All three tables have identical structures, and you want to combine the three tables into one table that is fragmented by expression on the common column acc_num. You want rows with acc_num less than or equal to 1120 to be stored in the fragment stored in dbspace1. Rows with acc_num greater than 1120 but less than or equal to 2000 are to be stored in dbspace2. Finally, rows with acc_num greater than 2000 are to be stored dbspace3.
9-36
Modifying a Fragmented Table
To fragment the tables with this fragmentation strategy, execute the following SQL statement:
ALTER FRAGMENT ON TABLE tab1 ATTACH tab1 AS acc_num <= 1120, tab2 AS acc_num > 1120 and acc_num <= 2000, tab3 AS acc_num > 2000
The result is a single table, tabl. The other tables, tab2 and tab3 were consumed and no longer exist. For more information on the ATTACH clause of the ALTER FRAGMENT statement, see Chapter 1 of the Informix Guide to SQL: Syntax.
Creating a Fragmented Table from a Single Nonfragmented Table

To create a fragmented table from a nonfragmented table, use the INIT clause of the ALTER FRAGMENT statement. For example, suppose you want to convert the table orders to a table fragmented by round robin. The following SQL statement performs the conversion:
ALTER FRAGMENT ON TABLE orders INIT FRAGMENT BY ROUND ROBIN
Note that any existing indexes on the nonfragmented table will become fragmented with the same fragmentation strategy as the table.
Modifying a Fragmented Table

You can make two general types of modications to a fragmented table. The rst type consists of the modications that you can make to a nonfragmented table. Such modications include adding a column, dropping a column, changing a column data type, and so on. For these modications, use the same SQL statements that you would normally use on a nonfragmented table. The second type of modication consists of changes to a fragmentation strategy. This section explains how to modify a fragmentation strategy using SQL statements.
Modifying Fragmentation Strategies
Modifying Fragmentation Strategies

The need to alter a fragmentation strategy after you implement fragmentation sometimes occurs. Most frequently, you will need to modify your fragmentation strategy when fragmentation is used with intraquery parallelization or interquery parallelization. Modifying your fragmentation strategy in these circumstances is one of several ways you can tune the performance of your OnLine system.
Change a Fragmentation Strategy Using the MODIFY Clause

You can modify an existing fragmentation strategy using the ALTER FRAGMENT statement. Use the MODIFY clause of the ALTER FRAGMENT statement to modify one or more of the expressions in a fragmentation strategy. For example, suppose that you initially created the fragmented table with the following CREATE TABLE statement:
CREATE TABLE account (acc_num INTEGER, ............) FRAGMENT BY EXPRESSION acc_num <= 1120 in dbspace1, acc_num > 1120 and acc_num < 2000 in dbspace2, REMAINDER IN dbspace3
Later, you want to ensure that no account numbers with a value less than or equal to zero are stored in the fragment contained in dbspace1. Executing the following ALTER FRAGMENT statement will accomplish this:
ALTER FRAGMENT ON TABLE account MODIFY dbspace1 to acc_num > 0 and acc_num <=1120
You cannot alter the number of fragments contained in your distribution scheme using the MODIFY clause. Use the INIT or ADD clause of ALTER FRAGMENT described in the next section instead.
9-38
Modifying Fragmentation Strategies Adding a New Fragment

If the modications that you want to make require adding a new fragment to your table, use the ADD clause of the ALTER FRAGMENT statement. For example, suppose that you want to add a fragment to a table that you created using the following SQL statement:
CREATE TABLE frag_table ... FRAGMENT BY ROUND ROBIN IN dbspace1,dbspace2,dbspace3
To add a fourth dbspace, dbspace4, execute the following SQL statement:

ALTER FRAGMENT ON TABLE frag_table ADD dbspace4
The ADD clause of ALTER FRAGMENT contains options for adding a dbspace before or after an existing dbspace, provided the fragmentation strategy is expression-based. See the ALTER FRAGMENT statement in Chapter 1 of the Informix Guide to SQL: Syntax for more information.
Completely Reinitialize a Fragmentation Scheme Using the INIT Clause

Consider using the INIT clause when you want to completely reinitialize a fragmentation strategy. For example, suppose that you initially created the fragmented table with the following CREATE TABLE statement:
CREATE TABLE account (acc_num INTEGER, ............) FRAGMENT BY EXPRESSION acc_num <= 1120 in dbspace1, acc_num > 1120 and acc_num < 2000 in dbspace2, REMAINDER IN dbspace3
However, you nd that after several months of operation with this distribution scheme, the number of rows in the fragment contained in dbspace2 is twice the number of rows contained in the other two fragments. This causes the disk containing dbspace2 to become an I/O bottleneck. To remedy this situation, you decide to modify the distribution so that the number of rows in each fragment is approximately even. You want to modify the distribution scheme so that instead of three fragments, it will contain four fragments. A new dbspace, dbspace2a, is to contain the new fragment that will store the rst half of the rows previously contained in dbspace2. The fragment contained in dbspace2 will contain the second half of the rows that it previously stored.
Dropping A Fragment
To implement the new distribution scheme, rst create the dbspace dbspace2a. Then execute the following statement:
ALTER FRAGMENT ON TABLE account INIT FRAGMENT BY EXPRESSION acc_num <= 1120 in dbspace1, acc_num > 1120 and acc_num <= 1500 in dbspace2a, acc_num > 1500 and acc_num < 2000 in dbspace2, REMAINDER IN dbspace3
As soon as you execute this statement, OnLine discards the old fragmentation strategy and the rows contained in the table are redistributed according to the new fragmentation strategy. You can also use the INIT clause of ALTER FRAGMENT to perform the following actions:
s s s
Convert a single nonfragmented table into a fragmented table Convert a fragmented table into a nonfragmented table Convert a table fragmented by round-robin to have an expressionbased fragmentation strategy Convert a table fragmented by expression to have a round robin fragmentation strategy
See the ALTER FRAGMENT statement in Chapter 1 of the Informix Guide to SQL: Syntax for more information.
Dropping A Fragment
In the process of dening a fragmentation strategy, you may nd it necessary to drop one or more fragments. Suppose you wish to drop a fragment that was dened by this SQL statement:
CREATE TABLE frag_table (col_a int, col_b int) FRAGMENT BY ROUND ROBIN IN dbspace1,dbspace2,dbspace3
To drop the second fragment, issue the following SQL statement:

ALTER FRAGMENT ON TABLE frag_table DROP dbspace2
When you issue this statement, all the rows in dbspace2 are moved to the remaining dbspaces, dbspace1 and dbspace3. For more information on dropping fragments, see the ALTER FRAGMENT statement in Chapter 1 of the Informix Guide to SQL: Syntax.
Accessing Data Stored in Fragmented Tables
Accessing Data Stored in Fragmented Tables

Rows stored in nonfragmented tables can be accessed by several methods. One method is to reference the rowid of the row you are seeking. The term rowid refers to an integer that denes the physical location of a row. OnLine assigns rows in a nonfragmented table a unique rowid, which allows applications access to a particular row in a table. Rows in fragmented tables, in contrast, are not assigned a rowid. If you wish to access data by rowid, you must explicitly create a rowid column as is described in the section Creating a Rowid Column on page 9-42. If user applications attempt to reference a rowid in a fragmented table that does not contain a rowid that you explicitly created, OnLine displays an appropriate error message and execution of the application is halted.
Use Primary Keys Instead of Rowids

Informix recommends that you use primary keys as a method of access in your applications rather than rowids. Because primary keys are dened in the ANSI specication of SQL, using them to access data makes your applications more portable. Refer to the Informix Guide to SQL: Reference and the Informix Guide to SQL: Syntax for a complete description on how to dene and use primary keys to access data.
Rowid in a Fragmented Table

From the viewpoint of an application, the functionality of a rowid column in a fragmented table is identical to the rowid of a nonfragmented table. However, unlike the rowid of a nonfragmented table, OnLine uses an index to map the rowid to a physical location. Accessing data in a fragmented table by rowid is signicantly slower than accessing data in a nonfragmented table by rowid. Accessing data in a fragmented table by rowid is no faster than accessing data using a primary key. In addition, primary key access can lead to signicantly improved performance in many situations, particularly when access is in parallel.
When OnLine accesses a row in a fragmented table using the rowid column, it uses an index to look up the physical address of the row before it attempts to access the row. For a nonfragmented table, OnLine uses direct physical access without having to do an index lookup. Consequently, accessing a row in a fragmented table using rowid takes slightly longer than accessing a row using rowid in a nonfragmented table. You should also expect a small performance impact on the processing of inserts and deletes due to the cost of maintaining the rowid index for fragmented tables. The section that follows explains how to create a rowid in a fragmented table.
Creating a Rowid Column

If, for some reason, you nd it obligatory that your applications access data in a fragmented table using a rowid column, you must create a rowid column for the fragmented table. You can create the column at the same time you create the table by using the WITH ROWIDS clause of the CREATE TABLE statement. When you issue the CREATE TABLE...WITH ROWIDS statement, OnLine creates a rowid column that adds 4 bytes to each row in the fragmented table. In addition, OnLine creates an internal index that it uses to access the data in the table by rowid. After the rowid column is created, OnLine inserts a row in the sysfragments catalog table, which indicates the existence and attributes of the rowid column. If you decide you need a rowid column after you build the fragmented table, use the ADD ROWIDS clause of the ALTER TABLE statement or the INIT clause of the ALTER FRAGMENT statement. You can drop the rowid column from a fragmented table with the DROP ROWIDS clause of the ALTER TABLE statement. See the ALTER TABLE statement in Chapter 1 of the Informix Guide to SQL: Syntax for more information. You cannot create or add a rowid column by naming it as one of the columns in a table you create or alter. For example, when you execute the statement, CREATE TABLE test_table (rowid INTEGER, ....) you get the -227 DDL options on rowid are prohibited. error.
Summary
Summary
This chapter covered the following work, which you must do to implement a data model:
s
Specify the domains, or constraints, that are used in the model, and complete the model diagram by assigning constraints to each column. Use interactive SQL to create the database and the tables in it. If you must create the database again, write the SQL statements to do so into a script of commands for the operating system. Populate the tables of the model, rst using interactive SQL and then by bulk operations. Possibly write the bulk-load operation into a command script so you can repeat it easily. Possibly use the fragmentation SQL statements to create, alter, and modify fragmented tables.
s s
You can now use and test your data model. If it contains very large tables, or if you must protect parts of it from certain users, more work remains to be done. That is one of the subjects in the INFORMIX-OnLine Dynamic Server Performance Guide.
Chapter

Controlling Access to Databases Securing Database Files . . Multiuser Systems . . Single-User Systems . Securing Condential Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 10-4 10-4 10-5 10-5 10-6 10-6 10-6 10-7 10-7 10-8 10-8 10-9 10-10 10-11 10-13 10-13 10-14 10-15 10-16 10-16 10-17 10-18 10-20
10
Granting Privileges . . . . . . . . . . Database-Level Privileges . . . . . . Connect Privilege. . . . . . . . Resource Privilege . . . . . . . Database Administrator Privilege . . Ownership Rights . . . . . . . . . Table-Level Privileges . . . . . . . Access Privileges . . . . . . . . Index, Alter, and References Privileges Column-Level Privileges . . . . . Procedure-Level Privileges . . . . . . Automating Privileges . . . . . . . Automating with INFORMIX-4GL . . Automating with a Command Script .
Controlling Access to Data Using Stored Procedures Restricting Reads of Data . . . . . . . . Restricting Changes to Data . . . . . . . Monitoring Changes to Data . . . . . . . Restricting Object Creation . . . . . . . .
Using Views . . . . . . . . . Creating Views . . . . . . . Duplicate Rows from Views . Restrictions on Views . . . When the Basis Changes . . Modifying Through a View. . . Deleting Through a View . . Updating a View . . . . . Inserting into a View. . . . Using WITH CHECK OPTION
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
10-21 10-22 10-23 10-23 10-24 10-25 10-25 10-25 10-26 10-27
Privileges and Views . . . . . . . . . . . . . . . . . . 10-28 Privileges When Creating a View. . . . . . . . . . . . . 10-28 Privileges When Using a View. . . . . . . . . . . . . . 10-29 Summary . . . . . . . . . . . . . . . . . . . . . . 10-32
10-2
I
s s s s
n some databases, all data is accessible to every user. In others, this is not the case; some users are denied access to some or all of the data. You can restrict access to data at the following levels, which are the subject of this chapter: When the database is stored in operating system les, you can sometimes use the le-permission features of the operating system. This level is not available when INFORMIX-OnLine Dynamic Server holds the database. It manages its own disk space and the rules of the operating system do not apply. You can use the GRANT and REVOKE statements to give or deny access to the database or to specic tables, and you can control the kinds of uses that people can make of the database. You can use the CREATE PROCEDURE statement to write and compile a stored procedure, which controls and monitors the users who can read, modify, or create database tables. You can use the CREATE VIEW statement to prepare a restricted or modied view of the data. The restriction can be vertical, excluding certain columns, or horizontal, excluding certain rows, or both. You can combine GRANT and CREATE VIEW statements to achieve precise control over the parts of a table a user can modify and with what data.
In addition to these points, INFORMIX-OnLine/Secure offers a type of automatic security called mandatory access control (MAC). With MAC, all users and all data are assigned a security label, and OnLine/Secure compares the labels before allowing access. For example, a user with the TOP SECRET label could view an UNCLASSIFIED row, but an UNCLASSIFIED user could not view a TOP SECRET row. This topic, and other topics related to security in OnLine/Secure are addressed in the INFORMIX-OnLine/Secure Security Features Users Guide.
10-3
Controlling Access to Databases
Controlling Access to Databases

The normal database-privilege mechanisms are based on the GRANT and REVOKE statements. They are covered in Granting Privileges on page 10-5. However, you can sometimes use the facilities of the operating system as an additional way to control access to a database.
Securing Database Files

Database servers other than INFORMIX-OnLine Dynamic Server store databases in operating system les. Typically, a database is represented as a number of les: one for each table, one for the indexes on each table, and possibly others. The les are collected in a directory. The directory represents the database as a whole.
Multiuser Systems
You can deny access to the database by denying access to the database directory. The means by which you can do this depend on your operating system and your computer hardware. Multiuser operating systems have software facilities such as UNIX le permissions.
Important: In UNIX, the database directory is created with group identity informix, and the database server always runs under group identity informix. Thus, you cannot use group permissions to restrict access to a particular group of users. You can, however, only remove all group permissions (le mode 700) and deny access to anyone except the owner of the directory.
You can also deny access to individual tables in this way; for example, by making the les that represent those tables unavailable to certain users, while leaving the rest of the les accessible. However, the database servers are not designed for tricks of this kind. When an unauthorized user tries to query one of the tables, the database server probably returns an error message about not being able to locate a le. This may confuse users.
10-4
Securing Condential Data Single-User Systems

Typical single-user systems have few software controls on le access; you can make a database inaccessible to others only by writing it on a disk that you can detach from the computer and keep locked. None of these techniques apply when you use the OnLine database server. It controls its own disk space at the device level, bypassing the le-access mechanisms of the operating system.
Securing Condential Data

No matter what access controls the operating system gives you, when the contents of an entire database are highly sensitive, you might not want to leave it on a public disk xed to the computer. You can circumvent normal software controls when the data must be secure. When the database is not being used by you or another authorized person, it does not have to be available on-line. You can make it inaccessible in one of the following ways, which have varying degrees of inconvenience:
s
Detach the physical medium from the computer, and take it away. If the disk itself is not removable, the disk drive might be removable. Copy the database directory to tape, and take possession of the tape. Copy the database les using an encryption utility. Keep only the encrypted version.
s s
In the latter two cases, after making the copies, you must remember to erase the original database les using a program that overwrites an erased le with null data. Instead of removing the entire database directory, you can copy and then erase the les that represent individual tables. However, do not overlook the fact that index les contain copies of the data from the indexed column or columns. Remove and erase the index les as well as the table les.
10-5
Granting Privileges
Granting Privileges
The authorization to use a database is called a privilege. For example, the authorization to use a database is called the Connect privilege, and the authorization to insert a row into a table is called the Insert privilege. You control the use of a database by granting these privileges to other users or by revoking them. Two groups of privileges exist that control the actions a user can perform on data. These are database-level privileges, which affect the entire database, and table-level privileges, which relate to individual tables. In addition to these two groups, procedure-level privileges exist, which determine who can execute a procedure.
Database-Level Privileges
The three levels of database privilege provide an overall means of controlling who accesses a database.
Connect Privilege
The least of the privilege levels is Connect, which gives a user the basic ability to query and modify tables. Users with the Connect privilege can perform the following functions:
s
Execute the SELECT, INSERT, UPDATE, and DELETE statements, provided that they have the necessary table-level privileges Execute a stored procedure, provided that they have the necessary table-level privileges Create views, provided that they are permitted to query the tables on which the views are based Create temporary tables and create indexes on the temporary tables
The Connect privilege is necessary before users can access a database. Ordinarily, in a database that does not contain highly sensitive or private data, you give the GRANT CONNECT TO PUBLIC privilege shortly after creating the database.
10-6
Database-Level Privileges
If you do not grant the Connect privilege to public, the only users who can access the database through the database server are those to whom you specically grant the Connect privilege. If limited users should have access, this is your means of providing it to them and denying it to all others.
The Users and the Public

Privileges are granted to single users by name or to all users under the name of PUBLIC. Any privileges granted to public serve as a default privileges. Prior to executing a statement, the database server determines whether a user has the necessary privileges. (The information is in the system catalog; see Privileges in the System Catalog on page 10-9.) The database server looks rst for privileges granted specically to the requesting user. If it nds such a grant, it uses that information. It then checks to see if less restrictive privileges have been granted to public. If so, the database server uses the less-restrictive privileges. If there has been no grant to that user, the database server looks for privileges granted to public. If it nds a relevant one, it uses that. Thus, you can set a minimum level of privilege for all users by granting privileges to public. You can override that, in specic cases, by granting higher individual privileges to users.
Resource Privilege
The Resource privilege carries the same authorization as the Connect privilege. In addition, users with the Resource privilege can create new, permanent tables, indexes, and stored procedures, thus permanently allocating disk space.
Database Administrator Privilege

The highest level of database privilege is Database Administrator, or DBA. When you create a database, you are automatically the DBA. Holders of the DBA privilege can perform the following functions:
s
Execute the DROP DATABASE, START DATABASE, and ROLLFORWARD DATABASE statements Drop or alter any object regardless of who owns it
Granting and Limiting Access to Your Database 10-7
Ownership Rights
s s
Create tables, views, and indexes to be owned by other users Grant database privileges, including the DBA privilege, to another user Alter the NEXT SIZE (but no other attribute) of the system catalog tables, and insert, delete, or update rows of any system catalog table except systables
Warning: Although users with the DBA privilege can modify most system catalog tables, Informix strongly recommends that you do not update, delete, or insert any rows in them. Modifying the system catalog tables can destroy the integrity of the database. Informix does support using the ALTER TABLE statement to modify the size of the next extent of system catalog tables.
Ownership Rights
The database, and every table, view, index, procedure, and synonym in it, has an owner. The owner of an object is usually the person who created it, although a user with the DBA privilege can create objects to be owned by others. The owner of an object has all rights to that object and can alter or drop it without needing additional privileges.
Table-Level Privileges
You can apply seven privileges, table by table, to allow nonowners the privileges of owners. Four of themthe Select, Insert, Delete, and Update privilegescontrol access to the contents of the table. The Index privilege controls index creation. The Alter privilege controls the authorization to change the table denition. The References privilege controls the authorization to specify referential constraints on a table. In an ANSI-compliant database, only the table owner has any privileges. In other databases, the database server, as part of creating a table, automatically grants all table privilegesexcept Alter and Referencesto public. This means that a newly created table is accessible to any user with the Connect privilege. If this is not what you wantif users exist with the Connect privilege who should not be able to access this tableyou must revoke all privileges on the table from public after you create the table.
10-8
Table-Level Privileges Access Privileges

Four privileges govern how users can access a table. As the owner of the table, you can grant or withhold the following privileges independently:
s
The Select privilege allows selection, including selecting into temporary tables. The Insert privilege allows a user to add new rows. The Update privilege allows a user to modify existing rows. The Delete privilege allows a user to delete rows.
s s s
The Select privilege is necessary for a user to retrieve the contents of a table. However, The Select privilege is not a precondition for the other privileges. A user can have Insert or Update privileges without having the Select privilege. For example, your application might have a usage table. Every time a certain program is started, it inserts a row into the usage table to document that it was used. Before the program terminates, it updates that row to show how long it ran and perhaps to record counts of work performed by its user. If you want any user of the program to be able to insert and update rows in this usage table, you grant Insert and Update privileges on it to public. However, you might grant the Select privilege to only a few users.
Privileges in the System Catalog

Privileges are recorded in the system catalog tables. Any user with the Connect privilege can query the system catalog tables to determine what privileges have been granted and to whom. Database privileges are recorded in the sysusers table, in which the primary key is user-id and the only other column contains a single character C, R, or D for the privilege level. A grant to the keyword of PUBLIC is reected as a user name of public (lowercase).
10-9
Table-level privileges are recorded in systabauth, which uses a composite primary key of the table number, grantor, and grantee. In the tabauth column, the privileges are encoded in a list as shown in the following diagram:
unconditional Update unconditional Select Insert Index References Alter
su-idxar
Delete
* if column privilege granted
A hyphen means an ungranted privilege, so that a grant of all privileges is shown as su-idxar, and -u------ shows a grant of only Update. The code letters are normally lowercase, but they are uppercase when the keywords WITH GRANT OPTION are used in the GRANT statement. When an asterisk (*) appears in the third position, some column-level privilege exists for that table and grantee. The specic privilege is recorded in syscolauth. Its primary key is a composite of the table number, the grantor, the grantee, and the column number. The only attribute is a three-letter list showing the type of privilege: s, u, or r.
Index, Alter, and References Privileges

The Index privilege permits its holder to create and alter indexes on the table. The Index privilege, similar to the Select, Insert, Update, and Delete privileges, is granted automatically to public when a table is created. You can grant the Index privilege to anyone, but to exercise the ability, the user must also hold the Resource database privilege. So, although the Index privilege is granted automatically (except in ANSI-compliant databases), users who have only the Connect privilege to the database cannot exercise their Index privilege. This is reasonable because an index can ll a large amount of disk space. The Alter privilege permits its holder to use the ALTER TABLE statement on the table, including the power to add and drop columns, reset the starting point for SERIAL columns, and so on. You should grant the Alter privilege only to users who understand the data model very well and whom you trust to exercise their power very carefully.
10-10
The References privilege allows you to impose referential constraints on a table. As with the Alter privilege, you should grant the References privilege only to users who understand the data model very well.
Column-Level Privileges
You can qualify the Select, Update, and References privileges with the names of specic columns. This allows you to grant very specic access to a table: You can permit a user to see only certain columns, you can allow a user to update only certain columns, or you can allow a user to impose referential constraints on certain columns. Using INFORMIX-OnLine Dynamic Server (so that table data can be inspected only through a call to the database server), this feature solves the problem that only certain users should know the salary, performance review or other sensitive attributes of an employee. To make the example specic, suppose a table of employee data is dened as shown in Figure 10-1.
CREATE TABLE hr_data ( emp_key INTEGER, emp_name CHAR(40), hire_date DATE, dept_num SMALLINT, user-id CHAR(18), salary DECIMAL(8,2) performance_level CHAR(1), performance_notes TEXT )
Figure 10-1 A table of condential employee information
Because this table contains sensitive data, you execute the following statement immediately after creating it:
REVOKE ALL ON hr_data FROM PUBLIC
For selected persons in the Human Resources department and for all managers, you execute a statement such as the one shown in the following example:
GRANT SELECT ON hr_data TO harold_r
10-11
In this way, you permit certain users to view all columns. (The nal section of this chapter discusses a way to limit the view of managers to only their employees.) For the rst-line managers who carry out performance reviews, you could execute a statement such as the one shown in the following example:
GRANT UPDATE (performance_level, performance_notes) ON hr_data TO wallace_s, margot_t
This statement permits the managers to enter their evaluations of their employees. Only for the manager of the Human Resources department or whomever is trusted to alter salary levels, would you execute a statement such as the one shown in the following example:
GRANT UPDATE (salary) ON hr_data to willard_b
For the clerks in the Human Resources department, you could execute a statement such as the one shown in the following example:
GRANT UPDATE (emp_key, emp_name, hire_date, dept_num) ON hr_data TO marvin_t
This statement gives certain users the ability to maintain the nonsensitive columns but denies them authorization to change performance ratings or salaries. The person in the MIS department who assigns computer user-ids is the beneciary of a statement such as the one shown in the following example:
GRANT UPDATE (user_id) ON hr_data TO eudora_b
On behalf of all users who are allowed to connect to the database but who are not authorized to see salaries or performance reviews, execute statements, such as the one shown in the following example, to permit them to see the nonsensitive data:
GRANT SELECT (emp_key, emp_name, hire_date, dept_num, user-id) ON hr_data TO george_b, john_s
These users can perform queries such as the one shown in the following example:
SELECT COUNT(*) FROM hr_data WHERE dept_num IN (32,33,34)
However, any attempt to execute a query, such as the one shown in the following example, produces an error message and no data:
SELECT performance_level FROM hr_data WHERE emp_name LIKE '*Smythe'
10-12
Procedure-Level Privileges
Procedure-Level Privileges
You can apply the Execute privilege on a procedure to authorize nonowners to run a procedure. If you create a procedure in a database that is not ANSIcompliant, the default procedure-level privilege is Public; you do not need to grant the Execute privilege to specic users unless you have rst revoked it. If you create a procedure in an ANSI-compliant database, no other users have the Execute privilege by default; you must grant specic users the Execute privilege. The following example grants the Execute privilege to the user orion so that orion can use the stored procedure named read-address:
GRANT EXECUTE ON read_address TO orion;
Procedure-level privileges are recorded in the sysprocauth system catalog table. The sysprocauth table uses a primary key of the procedure number, grantor, and grantee. In the procauth column, the execute privilege is indicated by a lowercase letter e. If the execute privilege was granted with the WITH GRANT option, the privilege is represented by an uppercase letter E. For more information on procedure-level privileges see Privileges on Stored Procedures on page 12-16.
Automating Privileges
It might seem that this design forces you to execute a tedious number of GRANT statements when you rst set up the database. Furthermore, privileges require constant maintenance as people change jobs. For example, if a clerk in Human Resources is terminated, you want to revoke the Update privilege as soon as possible; otherwise you risk the unhappy employee executing a statement such as the one shown in the following example:
UPDATE hr_data SET (emp_name, hire_date, dept_num) = (NULL, NULL, 0)
Less dramatic, but equally necessary, changes of privilege are required daily, or even hourly, in any model that contains sensitive data. If you anticipate this need, you can prepare some automated tools to help maintain privileges.
10-13
Your rst step should be to specify privilege classes that are based on the jobs of the users, not on the structure of the tables. For example, a rst-line manager needs the following privileges:
s
The Select and limited Update privilege on the hypothetical hr_data table The Connect privilege to this and other databases Some degree of privilege on several tables in those databases
s s
When the manager is promoted to a staff position or sent to a eld ofce, you must revoke all those privileges and grant a new set of privileges. Dene the privilege classes you support, and for each class specify the databases, tables, and columns to which you must give access. Then devise two automated procedures for each class, one to grant the class to a user and one to revoke it.
Automating with INFORMIX-4GL

The mechanism you use depends on your operating system and other tools. If you are a programmer, one of the tools you can use is INFORMIX-4GL. 4GL makes it quite easy to program a simple user interaction, as shown in the following example:
DEFINE mgr_id char(20) PROMPT 'What is the user-id of the new manager? ' FOR mgr_id CALL table_grant ('SELECT', 'hr_data', mgr_id)
Unfortunately, although INFORMIX-4GL allows you to mix GRANT and REVOKE statements freely with other program statements, it does not permit you to create parameters from them from program variables. To customize a GRANT statement with a user-id taken from user input, the program must build the statement as a string, prepare it with a PREPARE statement, and execute it with an EXECUTE statement. (These statements are discussed in detail in Chapter 5, Programming with SQL, where the following example is analyzed in detail.)
10-14
Figure 10-2 shows one possible denition of the 4GL function table_grant(), which is invoked by the CALL statement in the preceding example.
FUNCTION table_grant (priv_to_grant, table_name, user_id) DEFINE priv_to_grant char(100),{may include column-list} table_name CHAR(20), user_id CHAR(20), grant_stmt CHAR(200) LET grant_stmt =' GRANT ', priv_to_grant, ' ON ', table_name, ' TO ', user_id WHENEVER ERROR CONTINUE PREPARE the_grant FROM grant_stmt IF status = 0 THEN EXECUTE the_grant END IF IF status <> 0 THEN DISPLAY 'Sorry, got error #', status, 'attempting:' DISPLAY ' ', grant_stmt END IF WHENEVER ERROR STOP END FUNCTION
Figure 10-2 A 4GL function that builds, prepares, and executes a GRANT statement
Automating with a Command Script

Your operating system probably supports automatic execution of command scripts. In most operating environments, DB-Access and INFORMIX-SQL, the interactive SQL tools, accept commands and SQL statements to execute from the command line. You can combine these two features to automate privilege maintenance. The details depend on your operating system and the version of DB-Access or INFORMIX-SQL that you are using. In essence, you want to create a command script that performs the following functions:
s s
Takes a user-id whose privileges are to be changed as its parameter Prepares a le of GRANT or REVOKE statements customized to contain that user-id Invokes DB-Access or INFORMIX-SQL with parameters that tell it to select the database and execute the prepared file of GRANT or REVOKE statements
In this way, you can reduce the change of the privilege class of a user to one or two commands.
10-15
Controlling Access to Data Using Stored Procedures
Controlling Access to Data Using Stored Procedures

You can use a stored procedure to control access to individual tables and columns in the database. You can accomplish various degrees of access control through a procedure. (Stored procedures are fully described in Chapter 12, Creating and Using Stored Procedures.) A powerful feature of Stored Procedure Language (SPL) is the ability to designate a stored procedure as a DBA-privileged procedure. Writing a DBA-privileged procedure, you can allow users who have few or no table privileges to have DBA privileges when they execute the procedure. In the procedure, users can carry out very specic tasks with their temporary DBA privilege. The DBA-privileged feature allows you to accomplish the following tasks:
s
You can restrict how much information individual users can read from a table. You can restrict all the changes made to the database and ensure that entire tables are not emptied or changed accidentally. You can monitor an entire class of changes made to a table, such as deletions or insertions. You can restrict all object creation (data denition) to occur within a stored procedure so that you have complete control over how tables, indexes, and views are built.
Restricting Reads of Data

The procedure in Figure 10-3 on page 10-17 hides the SQL syntax from users, but it requires that users have the Select privilege on the customer table. If you want to restrict what users can select, you can write your procedure to work in the following environment:
s s
You are the DBA of the database. The users have the Connect privilege to the database. They do not have the Select privilege on the table. Your stored procedure (or set of stored procedures) is created using the DBA keyword. Your stored procedure (or set of stored procedures) reads from the table for users.
10-16
Restricting Changes to Data
If you want users to read only the name, address, and telephone number of a customer, you can modify the procedure as shown in Figure 10-3.
CREATE DBA PROCEDURE read_customer(cnum INT) RETURNING CHAR(15), CHAR(15), CHAR(18); DEFINE p_lname,p_fname CHAR(15); DEFINE p_phone CHAR(18); SELECT fname, lname, phone INTO p_fname, p_lname, p_phone FROM customer WHERE customer_num = cnum; RETURN p_fname, p_lname, p_phone; END PROCEDURE;
Figure 10-3 Stored procedure to restrict reads on customer data
Restricting Changes to Data

Using stored procedures, you can restrict changes made to a table. Simply channel all changes through a stored procedure. The stored procedure makes the changes, rather than users making the changes directly. If you want to limit users to deleting one row at a time to ensure that they do not accidentally remove all the rows in the table, set up the database with the following privileges:
s s
You are the DBA of the database. All the users have the Connect privilege to the database. They might have the Resource privilege. They do not have the Delete (for this example) privilege on the table being protected. Your stored procedure is created using the DBA keyword. Your stored procedure performs the deletion.
s s
10-17
Monitoring Changes to Data
Write a stored procedure similar to the one shown in Figure 10-4, which deletes rows from the customer table using a WHERE clause with the customer_num provided by the user.
CREATE DBA PROCEDURE delete_customer(cnum INT) DELETE FROM customer WHERE customer_num = cnum; END PROCEDURE;
Figure 10-4 Stored procedure to delete a row

Using stored procedures, you can create a record of changes made to a database. You can record changes made by a particular user, or you can make a record of each time a change is made. You can monitor all the changes made to the database by a single user. Simply channel all changes through stored procedures that keep track of changes made by each user. If you want to record each time the user acctclrk modies the database, set up the database with the following privileges:
s s
You are the DBA of the database. All other users have the Connect privilege to the database. They might have the Resource privilege. They do not have the Delete (for this example) privilege on the table being protected. Your stored procedure is created using the DBA keyword. Your stored procedure performs the deletion and records that a change has been made by a certain user.
s s
10-18
Write a stored procedure similar to the one in Figure 10-5, which updates a table using a customer number provided by the user. If the user happens to be acctclrk, a record of the deletion is put in the le updates.
CREATE DBA PROCEDURE delete_customer(cnum INT) DEFINE username CHAR(8); DELETE FROM customer WHERE customer_num = cnum; IF username = 'acctclrk' THEN SYSTEM 'echo Delete from customer by acctclrk >> /mis/records/updates' ; ENF IF END PROCEDURE;
Figure 10-5 A procedure to delete rows and record changes made by a certain user
You can monitor all the deletions made through the procedure by removing the IF statement and making the SYSTEM statement more general. If you change the procedure in Figure 10-5 to record all deletions, it looks like the procedure in Figure 10-6.
CREATE DBA PROCEDURE delete_customer(cnum INT) DEFINE username CHAR(8); LET username = USER ; DELETE FROM tbname WHERE customer_num = cnum; SYSTEM 'echo Deletion made from customer table, by '||username ||'>>/hr/records/deletes'; END PROCEDURE;
Figure 10-6 Stored procedure to delete rows and record user
10-19
Restricting Object Creation
Restricting Object Creation

To put restraints on what and how objects are built, use stored procedures within the following setting:
s s
You are the DBA of the database. All the other users have the Connect privilege to the database. They do not have the Resource privilege. Your stored procedure (or set of stored procedures) is created using the DBA keyword. Your stored procedure (or set of stored procedures) creates tables, indexes, and views in the way you dened them. You might use such a procedure to set up a training database environment.
Your procedure might include the creation of one or more tables and associated indexes, as shown in Figure 10-7.
CREATE DBA PROCEDURE all_objects() CREATE TABLE learn1 (intone SERIAL, inttwo INT NOT NULL, charcol CHAR(10) ); CREATE INDEX learn_ix ON learn1 (inttwo); CREATE TABLE toys (name CHAR(15) NOT NULL UNIQUE, description CHAR(30), on_hand INT); END PROCEDURE;
Figure 10-7 DBA-mode procedure that adds tables and indexes to the database
To use the all_objects procedure to control additions of columns to tables, revoke the Resource privilege on the database from all users. When users try to create a table, index, or view using an SQL statement outside your procedure, they cannot do so. When users execute the procedure, they have a temporary DBA privilege so the CREATE TABLE statement, for example, succeeds, and you are guaranteed that every column added has a constraint placed on it. In addition, objects created by users are owned by that user. For the all_objects procedure, the two tables and the index are owned by whoever executed the procedure.
10-20
Using Views
Using Views
A view is a synthetic table. You can query it as if it were a table, and in some cases, you can update it as if it were a table. However, it is not a table; rather, it is a synthesis of the data that exists in real tables and other views. The basis of a view is a SELECT statement. When you create a view, you dene a SELECT statement that generates the contents of the view at the time the view is accessed. A user also queries a view using a SELECT statement. The database server merges the SELECT statement of the user with the one dened for the view and then actually performs the combined statements. The result has the appearance of a table; it is similar enough to a table that a view even can be based on other views, or on joins of tables and other views. Because you write a SELECT statement that determines the contents of the view, you can use views for any of the following purposes:
s
To restrict users to particular columns of tables You name only permitted columns in the select list in the view. To restrict users to particular rows of tables You specify a WHERE clause that returns only permitted rows. To constrain inserted and updated values to certain ranges You can use the WITH CHECK OPTION (discussed on page 10-27) to enforce constraints.
To provide access to derived data without having to store redundant data in the database You write the expressions that derive the data into the select list in the view. Each time you query the view, the data is derived anew. The derived data is always up to date, yet no redundancies are introduced into the data model.
To hide the details of a complicated SELECT statement You hide complexities of a multitable join in the view so that neither users nor application programmers need to repeat them.
10-21
Creating Views
Creating Views
The following example creates a view based on a table in the stores7 database:
CREATE VIEW name_only AS SELECT customer_num, fname, lname FROM customer
The view exposes only three columns of the table. Because it contains no WHERE clause, the view does not restrict the rows that can appear. The following example creates a view based on a table that is available when NLS has been enabled. In it, the view, column, and table names contain foreign characters.
CREATE VIEW _va AS SELECT numro, nom FROM abonns;
The following example is based on the join of two tables:

CREATE VIEW full_addr AS SELECT address1, address2, city, state.sname, zipcode FROM customer, state WHERE customer.state = state.code
The table of state names reduces the redundancy of the database; it allows for storing the full state names only once, which can be very useful for lengthy state names such as Minnesota. This full_addr view lets users retrieve the address as if the full state name were stored in every row. The following two queries are equivalent:
SELECT * FROM full_addr WHERE customer_num = 105 SELECT address1, address2, city, state.sname, zipcode FROM customer, state WHERE customer.state = state.code AND customer_num = 105
However, be careful when you dene views that are based on joins. Such views are not modiable; that is, you cannot use them with UPDATE, DELETE, or INSERT statements. (Modifying through views is covered beginning on page 10-25.) The following example restricts the rows that can be seen in the view:
CREATE VIEW no_cal_cust AS SELECT * FROM customer WHERE NOT state = 'CA'
10-22
Creating Views
This view exposes all columns of the customer table, but only certain rows. The following example is a view that restricts users to rows that are relevant to them:
CREATE VIEW my_calls AS SELECT * FROM cust_calls WHERE user_id = USER
All the columns of the cust_calls table are available but only in those rows that contain the user-ids of the users who can execute the query.
Duplicate Rows from Views

It is possible for a view to produce duplicate rows, even when the underlying table has only unique rows. If the view SELECT statement can return duplicate rows, the view itself can appear to contain duplicate rows. You can prevent this problem in two ways. One way is to specify DISTINCT in the select list in the view. However, that makes it impossible to modify through the view. The alternative is to always select a column or group of columns that is constrained to be unique. (You can be sure only unique rows are returned if you select the columns of a primary key or of a candidate key. Primary and candidate keys are discussed in Chapter 8, Building Your Data Model.)
Restrictions on Views
Because a view is not really a table, it cannot be indexed, and it cannot be the object of such statements as ALTER TABLE and RENAME TABLE. The columns of a view cannot be renamed with RENAME COLUMN. To change anything about the denition of a view, you must drop the view and re-create it. Because it must be merged with the users query, the SELECT statement on which a view is based cannot contain any of the following clauses:
INTO TEMP UNION ORDER BY
The users query might contain INTO TEMP; if the view also contains it, the data would not know where to go. The users query might contain UNION. No meaning has been dened for nested UNION clauses. The users query might contain ORDER BY. If the view also contains it, the choice of columns or sort directions could be in conict.
Granting and Limiting Access to Your Database 10-23
Creating Views When the Basis Changes

The tables and views on which a view is based can change in several ways. The view automatically reects most of the changes. When a table or view is dropped, any views in the same database that depend on it are automatically dropped. The only way to alter the denition of a view is to drop and re-create it. Therefore, if you change the denition of a view on which other views depend, you must also re-create the other views (because they all have been dropped). When a table is renamed, any views in the same database that depend on it are modied to use the new name. When a column is renamed, views in the same database that depend on that table are updated to select the proper column. However, the names of columns in the views themselves are not changed. For an example of this, recall the following view on the customer table:
CREATE VIEW name_only AS SELECT customer_num, fname, lname FROM customer
Now suppose that the customer table is changed in the following way:
RENAME COLUMN customer.lname TO surname
To select last names of customers directly, you must now select the new column name. However, the name of the column as seen through the view is unchanged. The following two queries are equivalent:
SELECT fname, surname FROM customer SELECT fname, lname FROM name_only
When you alter a table by dropping a column, views are not modied. If they are used, error -217 (Column not found in any table in the query) occurs. The reason views are not dropped is that you can change the order of columns in a table by dropping a column and then adding a new column of the same name. If you do this, views based on that table continue to work. They retain their original sequence of columns.
INFORMIX-OnLine Dynamic Server permits you to base a view on tables and
views in external databases. Changes to tables and views in other databases are not reected in views. Such changes might not be apparent until someone queries the view and gets an error because an external table changed.
Modifying Through a View

It is possible to modify views as if they were tables. Some views can be modied and others not, depending on their SELECT statements. The restrictions are different, depending on whether you use DELETE, UPDATE, or INSERT statements. No modication is possible on a view when its SELECT statement contains any of the following features:
s
A join of two or more tables Many anomalies arise if the database server tries to distribute modied data correctly across the joined tables.
An aggregate function or the GROUP BY clause The rows of the view represent many combined rows of data; the database server cannot distribute modied data into them.
The DISTINCT keyword or its synonym UNIQUE The rows of the view represent a selection from among possibly many duplicate rows; the database server cannot tell which of the original rows should receive the modication.
When a view avoids all these things, each row of the view corresponds to exactly one row of one table. Such a view is modiable. (Of course, particular users can modify a view only if they have suitable privileges. Privileges on views are discussed beginning on page 10-28.)
Deleting Through a View

A modiable view can be used with a DELETE statement as if it were a table. The database server deletes the proper row of the underlying table.
Updating a View
You can use a modiable view with an UPDATE statement as if it were a table. However, a modiable view can still contain derived columns; that is, columns that are produced by expressions in the select list of the CREATE VIEW statement. You cannot update derived columns (sometimes called virtual columns).
10-25
When a column is derived from a simple arithmetic combination of a column with a constant value (for example, order_date+30), the database server can, in principle, gure out how to invert the expression (in this case, by subtracting 30 from the update value) and perform the update. However, much more complicated expressions are possible, most of which cannot easily be inverted. Therefore, the database server does not support updating any derived column. Figure 10-8 shows a modiable view that contains a derived column and an UPDATE statement that can be accepted against it.
CREATE VIEW call_response(user_id,received,resolved,duration)AS SELECT user_id,call_dtime,res_dtime, res_dtime -call_dtime FROM cust_calls WHERE user_id = USER UPDATE call_response SET resolved = TODAY WHERE resolved IS NULL
Figure 10-8 A modiable view and an UPDATE statement
The duration column of the view cannot be updated because it represents an expression (the database server cannot, even in principle, decide how to distribute an update value between the two columns named in the expression). But as long as no derived columns are named in the SET clause, the update can be performed as if the view were a table. A view can return duplicate rows even though the rows of the underlying table are unique. You cannot distinguish one duplicate row from another. If you update one of a set of duplicate rows (for example, by using a cursor to update WHERE CURRENT), you cannot be sure which row in the underlying table receives the update.
Inserting into a View

You can insert rows into a view provided that the view is modiable and contains no derived columns. The reason for the second restriction is that an inserted row must provide values for all columns, and the database server cannot tell how to distribute an inserted value through an expression. An attempt to insert into the call_response view, shown in Figure 10-8, would fail.
10-26
When a modiable view contains no derived columns, you can insert into it as if it were a table. However, the database server uses null as the value for any column that is not exposed by the view. If such a column does not allow nulls, an error occurs and the insert fails.
Using WITH CHECK OPTION

It is possible to insert into a view a row that does not satisfy the conditions of the view; that is, a row that is not visible through the view. It is also possible to update a row of a view so that it no longer satises the conditions of the view. If this is improper, you can add the clause WITH CHECK OPTION when you create the view. This clause asks the database server to test every inserted or updated row to ensure that it meets the conditions set by the WHERE clause of the view. The database server rejects the operation with an error if the conditions are not met. In Figure 10-8 on page 10-26, the view named call_response is dened as shown in the following example:
CREATE VIEW call_response(user_id,received,resolved,duration)AS SELECT user_id,call_dtime,res_dtime,res_dtime -call_dtime FROM cust_calls WHERE user_id = USER
It is possible to update the user_id column of the view, as shown in the following example:
UPDATE call_response SET user_id = 'lenora' WHERE received BETWEEN TODAY AND TODAY - 7
The view requires rows in which user_id equals USER. If this update is performed by a user named tony, the updated rows vanish from the view. However, you can create the view as shown in the following example:
CREATE VIEW call_response (user_id,received,resolved,duration) AS SELECT user_id,call_dtime,res_dtime,res_dtime-call_dtime FROM cust_calls WHERE user_id = USER WITH CHECK OPTION
The preceding update by tony is rejected as an error.
10-27
Privileges and Views
You can use the WITH CHECK OPTION feature to enforce any kind of data constraint that can be stated as a Boolean expression. In the following example, you can create a view of a table in which all the logical constraints on data are expressed as conditions of the WHERE clause. Then you can require all modications to the table to be made through the view.
CREATE VIEW order_insert AS SELECT * FROM orders O WHERE order_date = TODAY -- no back-dated entries AND EXISTS -- ensure valid foreign key (SELECT * FROM customer C WHERE O.customer_num = C.customer_num) AND ship_weight < 1000 -- reasonableness checks AND ship_charge < 1000 WITH CHECK OPTION
Because of EXISTS and other tests, which are expected to be successful when retrieving existing rows, this is a most inefcient view for displaying data from orders. However, if insertions to orders are made only through this view (and you are not already using integrity constraints to constrain data), it is impossible to insert a back-dated order, an invalid customer number, or an excessive shipping weight and shipping charge.
Privileges and Views

When you create a view, the database server tests your privileges on the underlying tables and views. When you use a view, only your privileges with regard to the view are tested.
Privileges When Creating a View

Therefore, , the database server tests to make sure that you have all the privileges needed to execute the SELECT statement in the view denition. If you do not, the view is not created. This test ensures that users cannot gain unauthorized access to a table by creating a view on the table and querying the view. After you create the view, the database server grants you, the creator and owner of the view, at least the Select privilege on it. No automatic grant is made to public, as is the case with a newly created table.
10-28
Privileges When Using a View
The database server tests the view denition to see if the view is modiable. If it is, the database server grants you the Insert, Delete, and Update privileges on the view, provided that you also have those privileges on the underlying table or view. In other words, if the new view is modiable, the database server copies your Insert, Delete, and Update privileges from the underlying table or view, and grants them on the new view. If you have only the Insert privilege on the underlying table, you receive only the Insert privilege on the view. This test ensures that users cannot use a view to gain access to any privileges that they did not already have. Because you cannot alter or index a view, the Alter and Index privileges are never granted on a view.

When you attempt to use a view, the database server tests only the privileges you are granted on the view. It does not test your right to access the underlying tables. If you created the view, your privileges are the ones noted in the preceding paragraph. If you are not the creator, you have the privileges that were granted to you by the creator or someone who had the WITH GRANT OPTION privilege. Therefore you can create a table and revoke public access to it; then you can grant limited access privileges to the table through views. This can be demonstrated through the previous examples using the hr_data table. Its denition is shown in Figure 10-9.
CREATE TABLE hr_data ( emp_key INTEGER, emp_name CHAR(40), hire_date DATE, dept_num SMALLINT, user-id CHAR(18), salary DECIMAL(8,2), performance_level CHAR(1), performance_notes TEXT )
Figure 10-9 A table of condential employee information
10-29
In Figure 10-9 on page 10-29, the example centered on granting privileges directly on this table. The following examples take a different approach. Assume that when the table was created, the following statement was executed:
REVOKE ALL ON hr_data FROM PUBLIC
(This is not necessary in an ANSI-compliant database.) Now you create a series of views for different classes of users. For those who should have read-only access to the nonsensitive columns, you create the following view:
CREATE VIEW hr_public AS SELECT emp_key, emp_name, hire_date, dept_num, user_id FROM hr_data
Users who are given the Select privilege for this view can see nonsensitive data and update nothing. For Human Resources personnel who must enter new rows, you create a different view, as shown in the following example:
CREATE VIEW hr_enter AS SELECT emp_key, emp_name, hire_date, dept_num FROM hr_data
You grant these users both Select and Insert privileges on this view. Because you, the creator of both the table and the view, have the Insert privilege on the table and the view, you can grant the Insert privilege on the view to others who have no privileges on the table. On behalf of the person in the MIS department who enters or updates new user-ids, you create still another view, as shown in the following example:
CREATE VIEW hr_MIS AS SELECT emp_key, emp_name, user_id FROM hr_data
This view differs from the previous view in that it does not expose the department number and date of hire.
10-30
Finally, the managers need access to all columns and need the ability to update the performance-review data for their own employees only. These requirements can be met by creating a table, hr_data, that contains a department number and a computer user-id for each employee. Let it be a rule that the managers are members of the departments that they manage. Then the following view restricts managers to rows that reect only their employees:
CREATE VIEW hr_mgr_data AS SELECT * FROM hr_data WHERE dept_num = (SELECT dept_num FROM hr_data WHERE user_id = USER) AND NOT user_id = USER
The nal condition is required so that the managers do not have update access to their own row of the table. It is, therefore, safe to grant the Update privilege to managers for this view, but only on selected columns, as shown in this statement:
GRANT SELECT, UPDATE (performance_level, performance_notes) ON hr_mgr_data TO peter_m
10-31
Summary
Summary
In a database that contains public material or is used only by you and trusted associates, security is not an important consideration and few of the ideas in this chapter are needed. But as more people are allowed to use and modify the data, and as the data becomes increasingly condential, you must spend more time and be ever more ingenious at controlling the way people can approach the data. The techniques discussed here can be divided into the following groups:
s
Keeping data condential When the database resides in operating system les you can use features of the operating system to deny access to the database. In any case, you control the granting of the Connect privilege to keep people out of the database. When different classes of users have different degrees of authorization, you must give them all the Connect privilege. You can use tablelevel privileges to deny access to condential tables or columns. Or, you can use a stored procedure to provide limited access to condential tables or columns. In addition, you can deny all access to tables and allow it only through views that do not expose condential rows or columns.
Controlling changes to data and database structure You safeguard the integrity of the data model by restricting grants of the Resource, Alter, References, and DBA privileges. You ensure that only authorized persons modify the data by controlling the grants of the Delete and Update privileges, and by granting the Update privilege on as few columns as possible. You ensure that consistent, reasonable data is entered by granting the Insert privilege only on views that express logical constraints on the data. Alternatively, you can control the insertion and modication of data, or the modication of the database itself, by limiting access to constrictive stored procedures.
10-32
Chapter
Understanding Informix Networking

What Is a Network? . . . . . . . . . . . . . . . . . . 11-4 11-4 11-5 11-6 11-7 11-8 11-9 11-10 11-10 11-11 11-12 11-12 11-13 11-14 11-15 11-16 11-17 11-17 11-18 11-19 11-20
11
Database Management System Congurations . . . . . . . . . A Single-User Conguration . . . . . . . . . . . . . . Advantages and Disadvantages of a Single-User System . . . A Local Multiuser Conguration. . . . . . . . . . . . . Advantages and Disadvantages of Local Multiuser Systems . . A Remote Conguration . . . . . . . . . . . . . . . Advantages and Disadvantages of Remote Network Connections Single-Computer Conguration Using Network Communication . Advantages and Disadvantages of Local Loopback . . . . . Distributed Databases . . . . . . . . . . . . . . . . Advantages and Disadvantages of Distributed Databases . . . Distributed Databases Using Multiple Vendor Servers . . . . . Connecting to Data on a UNIX Network . Example of Client / Server Connections Environment Variables . . . . . . Connection Information . . . . . . SQL Connection Statements . . . . Accessing Tables. . . . . . . . . Using Synonyms with Table Names. Synonym Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting Your Data in a Networked Environment. . . . Data Protection with INFORMIX-SE . . . . . . . Data Protection with INFORMIX-OnLine Dynamic Server Data Replication . . . . . . . . . . . . . Archives . . . . . . . . . . . . . . . . Data Integrity for Distributed Data . . . . . . . . Two-Phase Commit . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . .
. . . . 11-21 . . . . 11-21 . . . . 11-21 . . . . 11-21 . . . . 11-22 . . . . 11-22 . . . . 11-22 . . . . 11-23
11-2
T
s s s s
his chapter gives an overview of the use of databases on a computer network. It introduces some commonly used terminology and illustrates various network congurations. The chapter also presents an overview of how the components of either a local or network connection t together so that a client application can nd data on a database server. This chapter discusses the following networking congurations that you can use with Informix databases and point out some of their effects on performance and usability: All on one computer A simple network connection Multiple connections on a network Data managed by non-Informix database servers (INFORMIX-TP/XA)
It is not enough to simply build a computer network; you have to re-examine how your applications and database servers share data. This chapter also covers the following topics concerned with managing data shared over a network:
s s s s s
Distributed data Connecting to data Protecting your data Synonym chains Network transparency
The nal sections of the chapter discuss protecting your data in a networked environment.
Understanding Informix Networking 11-3
What Is a Network?
What Is a Network?
A computer network is a group of computers, workstations, and other devices connected together over a communications system to share resources and data. A network site is simply the location of one of the computers on the network. Sometimes the network sites are widely separated, but they might also be in the same room or building. Two network sites can even coexist on the same computer. To make a practical computer network work, you must master a multitude of technical details regarding hardware and software. There are far too many details, and they change too rapidly to cover them in this book. This chapter gives a conceptual discussion of some of the issues that you might encounter when you use a computer network. For more information, refer to the manual that accompanies the Informix client/server product that you use and to the manuals provided by the vendor of your operating system.
Database Management System Congurations

A relational database management system (RDBMS) includes all the components necessary to create and maintain a relational database. An Informix RDBMS has several pieces: the user interface, the database server, and the data itself. It is easiest to think of these pieces as all being located in the same computer, but many other arrangements are possible. In some arrangements, the application and the database server are on different computers, and the data is distributed across several others. The client applications of an RDBMS do not need to be modied to run on a network. The communications tools that are part of all Informix products handle the tasks of locating and attaching to the database servers. To the application, a database on a networked computer appears no different than a database on the computer where the application resides.
11-4
A Single-User Conguration
Figure 11-1 shows a diagram of a simple database management system on a single computer. The organization in Figure 11-1 is one you would typically nd on a personal computer running DOS. It is unusual to have a single-user situation on a UNIX system, but you certainly can. One example of a singleuser UNIX system would be a desktop workstation in a development environment.
personal computer
Figure 11-1 A database management system on a personal computer
Connection
INFORMIX-SE
application user databases
The components of the system in Figure 11-1 on page 11-5 are described in the following list:
s
An application program Any program that issues a query can be the application. It could, for example, be a program written in INFORMIX-4GL, a C language program with embedded SQL, or compiled screen forms and reports.
A connection On a simple system such as this one, the communication component is frequently so well integrated with the system that it is omitted from diagrams and not discussed. However, it does exist.
A database server The database server receives queries from the application, searches the database, and returns information to the application. The database server manages or administers the databases that it controls. The database server in Figure 11-1 is a local server because it resides on the same host computer as the client application.
A database Databases are usually stored on a magnetic disk. If this system were a UNIX system with INFORMIX-OnLine Dynamic Server, the database might be located on some other medium, such as a WORM (writeonce read-many-times) drive controlled by INFORMIX-OnLine/Optical.
Advantages and Disadvantages of a Single-User System

A conguration involving only one computer is the easiest conguration to set up and maintain, and it gives the fastest access to data. However, the data is not available to users on other computers and the size of the databases or the amount of processing needed may outgrow the capacity of the computer.
11-6
A Local Multiuser Conguration

Figure 11-2 shows another database management system conguration, a multiuser system with a local database server such as one you might nd on a computer with a UNIX operating system.
Unix Computer
Figure 11-2 A database management system on a UNIX computer
application user Connection databases
application user
database server
The components of the systems in Figure 11-2 are similar to the components in Figure 11-1 on page 11-5, as described in the following list:
s
Application programs Two or more applications use the same database server to access information in the databases. You might have two users at individual terminals, as shown, or you might have multiple windows on a single workstation.
A connection On a local UNIX system, the following types of connection are possible:
u u
Network connection Interprocess communication (IPC)

IPC is a UNIX feature that transfers information very quickly
between the application and the database server. It is available only when the application and the database server reside on the same computer. INFORMIX-SE databases use a type of IPC connection called unnamed pipes and INFORMIX-OnLine Dynamic Server databases use an IPC connection technique called shared memory.
s
A database server, either INFORMIX-OnLine Dynamic Server or INFORMIX-SE Databases
Advantages and Disadvantages of Local Multiuser Systems

A conguration that allows multiple users gives better access to the data than does a single-user system. With a local database, it is still easy to set up and maintain. However, as with the single-user system, the data is not available to users on other computers and the size of the databases or the amount of processing needed may outgrow the capacity of the computer.
IPC shared memory provides very fast communication between the client application and the database server. However, IPC shared memory
communication is vulnerable to programming errors if the client application does explicit memory addressing or overindexes data arrays. Such errors do not affect the application if you use IPC unnamed pipes or network communication. (See Single-Computer Conguration Using Network Communication on page 11-10.)
11-8
A Remote Conguration
A Remote Conguration
Figure 11-3 shows a remote or network conguration, where the application resides on one computer and the database server and its associated databases reside on another computer on the network. In contrast, the database servers in Figure 11-1 on page 11-5 and Figure 11-2 on page 11-7 are local database servers.
Figure 11-3 A simple network connection
host 1 host 2
application user network connection application user network connection
database server databases
In Figure 11-3 the applications might be INFORMIX-ESQL/COBOL or INFORMIX-ESQL/C applications. The database server might be INFORMIX-OnLine Dynamic Server (UNIX) or INFORMIX-SE for Windows NT. Different computers are referred to as sites or host computers. The database server in Figure 11-3 is a remote database server because it is on a different host computer, from the application that uses its services. A database server can be local with respect to one application and remote with respect to another application, as illustrated in Figure 11-6 on page 11-15.
Single-Computer Conguration Using Network Communication Advantages and Disadvantages of Remote Network Connections
The conguration shown in Figure 11-3 on page 11-9 is an example of distributed processing. In distributed processing, multiple computers contribute to a single computing task. In this example, host1 handles the computing requirements of the application, such as screen display, generation of reports, and printing; host2 handles the computing required to manipulate information in the databases. Using a network also gives the client application the opportunity to access data from several computers. Response from a database server using network communication is not as fast as response from a database server using IPC because of the extra computing required to prepare the data for network communication and because of the transmit time. A network is somewhat more difcult to congure and maintain than a local system that uses IPC communication.
Single-Computer Conguration Using Network Communication

Figure 11-4 on page 11-11 shows a conguration that behaves as if there were multiple sites residing on one computer. In this conguration, which is known as local loopback, all the components are on the same computer, but the connections are made as if they were connected through a network. Because the connections use network software, the database server appears to the application as a remote site. The dashed line indicates the division between the two sites. The database administrator congures the system to provide local or local loopback connections (or both).
11-10
Single-Computer Conguration Using Network Communication
The software for the client application and the software for the database server can be stored in the same directory, or the software can be stored in two separate directories.
computer
Figure 11-4 An example of local loopback
client site application user network connection
server site
database server databases
Advantages and Disadvantages of Local Loopback

Local loopback allows you to test network operations without requiring an actual remote computer , but it is not as fast as a IPC. However, unlike IPC shared-memory communication, local loopback is not vulnerable to corruption due to memory-addressing errors or overindexed data arrays. (See Advantages and Disadvantages of Local Multiuser Systems on page 11-8.)
Distributed Databases
Distributed Databases
Although a network lets you separate the application from the data, the application still is limited to the contents of a single database. With most database servers, you can query or modify tables only in the current database. A distributed database has information on multiple databases that are organized to appear as a a single database to the user. The data can be maintained by a variety of database servers and located on computers supported by different operating systems and communication networks. The OnLine database server allows you to query data in multiple databases anywhere on the network. When the INFORMIX-TP/XA feature is added to INFORMIX-OnLine Dynamic Server, you can create global transactions that span multiple computer systems and even multiple XA-compliant database systems from different vendors. INFORMIX-SE does not provide distributed database processing capabilities. The INFORMIX-Gateway with DRDA allows you to perform distributed queries that include non-Informix databases that conform to the distributed relational database architecture (DRDA) protocols dened by IBM.
Advantages and Disadvantages of Distributed Databases

You may nd distributed databases useful because operations that use databases are often naturally distributed into separate pieces, either organizationally, geographically, or both. A distributed database system includes the following advantages:
s
Local data can be kept locally where it is most easily maintained and most frequently used. Data from remote sites is available to all users. Duplicate copies can be maintained for safety of the data.
s s
A distributed database system has the following disadvantages:

s
Management of the distributed system is more involved than management of a single-host system. Network access is slower than local access.
11-12
Distributed Databases Using Multiple Vendor Servers
Distributed Databases Using Multiple Vendor Servers

INFORMIX-TP/XA allows you to use database management systems from multiple vendors to store and access your data. INFORMIX-TP/XA is a library of functions that allows the INFORMIX-OnLine Dynamic Server database
server to act as a resource manager in a distributed transaction-processing (DTP) environment that follows an interface standard, which was dened by the X/Open Company. The terminology used by the XA standard is different from the terminology used by Informix products and documentation. A transaction manager acts as an intermediary and relays requests from a user interface to a resource manager. Transaction managers are third-party products such as TUXEDO. In this context, a resource manager corresponds to a database server. Figure 11-5 illustrates a conguration that uses transaction processing.
Figure 11-5 A conguration using a transaction manager
transaction manager interface user Vendor a DBMS/XA interface user Vendor b DBMS/XA INFORMIX OnLine/XA
client portion of each application
server portion of each application
resource managers
databases
Connecting to Data on a UNIX Network
Connecting to Data on a UNIX Network

When the application and data are moved to separate computers, two questions immediately arise: What connections can you implement? How do you instruct your applications to nd the data that is now somewhere else? In fact, connecting a client application to a database server that is on a networked computer is no different from connecting to a local database server. To connect a client application with a database, you must consider the following parts of your conguration:
s s s
Environment variables Connection information Connection statements
This section summarizes how connections are made for Version 6.0 and later clients and servers. Detailed instructions for setting up local and network connections, as well as for those between Version 6.0 servers and earlier clients are given in the INFORMIX-OnLine Dynamic Server Administrators Guide, the INFORMIX-SE Administrators Guide and the INFORMIX-Gateway with DRDA User Manual.
11-14
Example of Client / Server Connections
Example of Client / Server Connections

Figure 11-6 shows local and networked connections of Version 6.0 and later products. Although all these connections are possible, you cannot do them all at once. Client X can make connection 1, 2, or 3, and Client Y can make connection 4 or 5.
Host 1 Host 2 Figure 11-6 Local and network connection of Version 6.0 and later products 7.1 Client Y
4
A OnLine 7.1
B OnLine 7.1
2 1
Daemon sqlexecd
7.1 Client X
3
SE 7.1
You can connect clients directly to OnLine database servers using either shared memory (IPC) or a network communications. Notice also that OnLine database servers (OnLine A and OnLine B) can communicate with each other. Local clients can connect directly to an INFORMIX-SE database server using unnamed pipes (IPC). Clients using network communications connect to INFORMIX-SE by connecting rst to a daemon, sqlexecd. A daemon is a background process that listens for requests from other programs. The sqlexecd daemon is started by the system administrator. When a client requests a connection to an INFORMIX-SE database server, sqlexecd notices the request and creates a temporary (light gray arrows) connection between the client and SE. This temporary connection (shown as (3) - (1) in Figure 11-6) enables the client and INFORMIX-SE database server to establish a direct connection (3). Then sqlexecd removes itself from the loop, leaving the client attached to the SE database server.
Environment Variables
Environment Variables
The Informix administrator must make sure that each user sets the correct environment variables. The following list shows the most important environment variables used by OnLine and INFORMIX-SE:
s s s s s s
PATH INFORMIXDIR INFORMIXSERVER TERM DBPATH ONCONFIG
The INFORMIXDIR environment variable must be set to the full pathname of the directory where the Informix les reside. The PATH environment variable must include the full pathname of the directory where the executables for INFORMIX-SE and/or INFORMIX-OnLine Dynamic Server reside. These two environment variables are required. After the Informix administrator has specied them, you usually do not change them. The INFORMIXSERVER environment variable is the name of the default database server. It is also a required variable. You may choose to change INFORMIXSERVER when you change applications. The TERM (or TERMCAP and/or INFORMIXTERM) environment variable enables the clients to recognize and communicate with your terminal. These variables are system- and terminal-dependent. To set them, you may need the assistance of your system administrator. The DBPATH environment variable is optional. If the application does not fully specify the location of an SE database server, the directories listed in DBPATH are searched by the database server to nd the specied database. The DBPATH environment variable is also used to specify directory names for reports, forms, and command les used by both INFORMIX-OnLine Dynamic Server and INFORMIX-SE. The ONCONFIG environment variable is required when OnLine is initialized: It is not used by SE. These environment variables are described in detail in Chapter 4 of the Informix Guide to SQL: Reference.
Connection Information
Connection Information
The location of the database server and the type of connection (protocol) for the database server are specied in the $INFORMIXDIR/etc/sqlhosts le. Each database server that might be accessed by an application must have an entry in sqlhosts le on every computer on the network. In addition to the sqlhosts les, TCP/IP connections require entries in the UNIX systems les, /etc/hosts and /etc/services. IPX/SPX connections also require auxiliary les, However, unlike TCP/IP, the names of the auxiliary les depend on the hardware vendor. Informix database servers follow UNIX security requirements for making connections. Thus, the UNIX system administrator may need to make modications to the /etc/passwd, /etc/hosts, rhosts and other related les. These les are described in the INFORMIX-OnLine Dynamic Server Administrators Guide, the INFORMIX-SE Administrators Guide, the INFORMIX-Gateway with DRDA User Manual, and in operating system manuals.
SQL Connection Statements

Before it can do anything else, the client application must open a database by executing a CONNECT statement or a DATABASE statement. The CONNECT statement is preferred because it conforms with both ANSI and X/Open standards, which attempt to specify uniform syntax for networked and nonnetworked environments. The following command is an example of the CONNECT statement:
CONNECT TO databasename@servername
If the servername is omitted from the statement, the application connects to the default database server specied by the INFORMIXSERVER environment variable. If the databasename is omitted, the application connects to the database server servername but does not open a database. Before you can use a database, you must issue a DATABASE, CREATE DATABASE, or START DATABASE statement.
Accessing Tables
Notice that the CONNECT statement does not give any information about the location of the database server. The location information for the database server is in the sqlhosts le. (Refer to Connection Information on page 11-17.) The complete syntax for the CONNECT and DATABASE statements is covered in Chapter 1 of the Informix Guide to SQL: Syntax.
Accessing Tables
The database that is opened by a CONNECT, DATABASE or CREATE DATABASE statement is the current database. If you are using INFORMIX-OnLine Dynamic Server, you can query tables that are not in the current database. To refer to a table in a database other than the current database, include the database name as part of the table name, as illustrated in the following SELECT statement:
SELECT name, number FROM salesdb:contacts
The database is salesdb. The table in salesdb is named contacts. You can use the same notation in a join. When you must specify the database name explicitly, the long table names can become cumbersome unless you use aliases to shorten them, as shown in the following example:
SELECT C.custname, S.phone FROM salesdb:contacts C, stores:customer S WHERE C.custname = S.company
To specify a table in a database that is managed by a different OnLine database server, you must qualify the database name with a database server name. For example, the following SELECT statement refers to table customer from database masterdb, which resides on the database server central:
SELECT O.order_num, C.fname, C.lname FROM masterdb@central:customer C, sales@boston:orders O WHERE C.customer_num = O.Customer_num INTO TEMP mycopy
In the example, two tables are being joined. The joined rows are stored in a temporary table mycopy in the current database. The tables are located in two database servers, central and boston.
11-18
Using Synonyms with Table Names
Informix allows you to overqualify (to give more information than is required) table names. Because both table names are fully qualied, you cannot tell whether the current database is masterdb or sales.
Using Synonyms with Table Names

A synonym is a name that you can use in place of another name. The main use of the CREATE SYNONYM statement is to make it more convenient to refer to tables that are not in the current database. The preceding example has been revised, as shown in the following example, to use synonyms for the table names:
CREATE SYNONYM mcust FOR masterdb@central:customer; CREATE SYNONYM bords FOR sales@boston:orders; SELECT bords.order_num, mcust.fname, mcust.lname FROM mcust, bords WHERE mcust.customer_num = bords.Customer_num INTO TEMP mycopy;
The CREATE SYNONYM statement stores the synonym name in the system catalog table syssyntable in the current database. The synonym is available to any query made within that database. A short synonym makes it easier to write queries, but synonyms can play another role. They allow you to move a table to a different database, or even to a different computer, while leaving your queries the same. Suppose you have several queries that refer to the tables customer and orders. The queries are embedded in programs, forms, and reports. The tables are part of database stores7, which is kept on database server avignon. Now the decision is made that the same programs, forms, and reports are to be made available to users of a different computer on the network (database server nantes). Those users have a database that contains a table named orders containing the orders at their location, but they need access to the table customer at avignon.
Synonym Chains
To those users, the customer table is external. Does this mean you must prepare special versions of the programs and reports, versions in which the customer table is qualied with a database server name? A better solution is to create a synonym in the users database, as shown in the following example:
DATABASE stores7@nantes; CREATE SYNONYM customer FOR stores7@avignon:customer;
When the stored queries are executed in your database, the name customer refers to the actual table. When they are executed in the other database, the name is translated through the synonym into a reference to the external table.
Synonym Chains
To continue the preceding example, suppose that a new computer is added to your network. Its name is db_crunch. The customer table and other tables are moved to it to reduce the load on avignon. You can reproduce the table on the new database server easily enough, but how can you redirect all accesses to it? One way is to install a synonym to replace the old table, as shown in the following example:
DATABASE stores7@avignon EXCLUSIVE; RENAME TABLE customer TO old_cust; CREATE SYNONYM customer FOR stores7@db_crunch:customer; CLOSE DATABASE;
When you execute a query within stores7@avignon, a reference to table customer nds the synonym and is redirected to the version on the new computer. This is also true of queries executed from database server nantes. The synonym in the database stores7@nantes still redirects references to customer to database stores7@avignon; however, the new synonym there sends the query to database stores7@db_crunch. Chains of synonyms can be useful when, as in this example, you want to redirect all access to a table in one operation. However, you should update all users databases as soon as possible so their synonyms point directly to the table. You incur extra overhead in handling the extra synonyms and, if any computer in the chain is down, the table cannot be found.
11-20
Protecting Your Data in a Networked Environment
It is possible to run an application against a local database and later to run the identical application against a database on another computer. The program runs equally well in either case (although it may run more slowly on the network database). As long as the data model is the same, a program cannot tell the difference between a local database server and a remote one.
Protecting Your Data in a Networked Environment

This section gives an overview of data-protection features used on a network. Chapter 4, Modifying Data, has a general discussion of data protection.
Data Protection with INFORMIX-SE

INFORMIX-SE databases use the normal UNIX le structures, so SE databases can be archived with the usual operating system backup procedures. On a network, you can write the archives to a device in another location.
Data Protection with INFORMIX-OnLine Dynamic Server

OnLine includes several tools that make multiple copies of data. Each one has its own unique task in the area of data protection. The following discussions give a general description of these tools and highlight the distinctions between them.
Data Replication
In a general sense, data replication means that a given piece of data has several distinct representations on several distinct servers. OnLine does data replication by using two networked computers. Each computer has an OnLine database server and databases that have identical characteristics. One database server is the primary and the other is the secondary. Data is always written to the primary server and then transferred to the secondary server. Applications can read data from either database server. Thus the secondary site can provide a dual purpose: It provides data protection and improved performance for users at the secondary site who need to readbut not writedata.
Data Integrity for Distributed Data
If the primary database server (call it serverA) fails for any reason, the secondary server (call it serverB) can become an independent database server. Users who would normally use serverA can be switched to serverB. Service to all the users can continue with a minimum of disruption while serverA is being repaired. Data replication provides good data protection and continuity of service, but it is expensive: Memory must be provided for two complete copies of the data, shipping the data to a remote site affects performance, and management requires the attention of the OnLine administrators on both sites.
Archives
OnLine provides specialized tools for making archives. Archives can be prepared locally or on a networked computer. Archives should be stored in a location that is physically removed from the database server, so it may be convenient to build the archives on a networked computer located at a different physical site. For descriptions of archiving tools for OnLine, see the INFORMIX-OnLine Dynamic Server Archive and Backup Guide.
Data Integrity for Distributed Data

OnLine allows you to update data in several databases on different database servers. For example, a purchase order (a single transaction) might require updating information in databases on different database servers. To maintain the integrity of the data, it is essential that either all the different databases are updated or none of the databases are updated.
Two-Phase Commit
Two-phase commit is a protocol that coordinates work performed at multiple database servers on behalf of a single transaction. Unlike the data-replication and archiving tools discussed earlier in this section, two-phase commit does not make two copies of the data. It protects the validity of one transaction that involves several databases. Because two-phase commit involves only one transaction, it is not usually considered as data protection.
11-22
Summary
A transaction that involves multiple database servers is called a global transaction. Two-phase commit is a natural extension of transaction handling, which is discussed in Interrupted Modications on page 4-25. The INFORMIX-OnLine Dynamic Server Administrators Guide discusses two-phase commit in detail. The two-phase commit begins when a client application has completed all its work and requests a commit of the global transaction.
Phase 1
The current database server asks each participating database server if it can commit its local transactions. Each database server responds Yes or No.
Phase 2
If all the database servers respond afrmatively, the current database server tells each one to commit its transactions and then the global transaction is complete. If any database server responds negatively or does not respond, all database servers are instructed to abort the local transactions.
Summary
A network allows a client application to run on one computer, while the database server operates in another computer to which the data is physically attached. This provides distributed processing and the possibility of distributed database access. Many possible combinations exist of network software, operating systems, and database servers, and each has subtleties that must be mastered.
Using Advanced SQL
Section III
Chapter
Creating and Using Stored Procedures

Introduction to Stored Procedures and SPL . . . . . What You Can Do with Stored Procedures . . . . Relationship Between SQL and a Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3 12-4 12-4 12-5 12-6 12-6 12-7 12-7 12-8 12-8 12-9 12-10 12-10 12-11 12-11 12-13 12-13 12-15 12-16 12-17 12-17 12-17 12-18 12-18 12-19
12
Creating and Using Stored Procedures . . . . . . . . . Creating a Procedure Using DB-Access . . . . . . . Creating a Procedure in a Program . . . . . . . . . Commenting and Documenting a Procedure . . . . . Diagnosing Compile-Time Errors . . . . . . . . . Finding Syntax Errors in a Procedure Using DB-Access Finding Syntax Errors in a Procedure Using an SQL API Looking at Compile-Time Warnings . . . . . . . . Generating the Text or Documentation. . . . . . . . Looking at the Procedure Text . . . . . . . . . Looking at the Procedure Documentation . . . . . Executing a Procedure . . . . . . . . . . . . . Executing a Stored Procedure Dynamically . . . . . . Debugging a Procedure . . . . . . . . . . . . . Re-creating a Procedure . . . . . . . . . . . Privileges on Stored Procedures . . . Privileges Necessary at Creation . . Privileges Necessary at Execution . Owner-Privileged Procedures . DBA-Privileged Procedures . . Privileges and Nested Procedures Revoking Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variables and Expressions . . . . . Variables . . . . . . . . . . Format of Variables . . . . . Global and Local Variables . . Dening Variables . . . . . Data Types for Variables . . . Using Subscripts with Variables . Scope of Variables . . . . . Variable/Keyword Ambiguity . SPL Expressions . . . . . . . Assigning Values to Variables .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
12-19 12-19 12-19 12-20 12-20 12-21 12-21 12-22 12-22 12-24 12-24
Program Flow Control . . . . . . . . . . . . . . . . . . 12-25 Branching . . . . . . . . . . . . . . . . . . . . . 12-25 Looping . . . . . . . . . . . . . . . . . . . . . 12-26 Function Handling . . . . . . . . . . . . . . . . . 12-27 Calling Procedures Within a Procedure . . . . . . . . . 12-27 Running an Operating System Command from Within a Procedure 12-27 Recursively Calling a Procedure. . . . . . . . . . . . 12-27 Passing Information into and out of a Procedure. . . . . . . Returning Results . . . . . . . . . . . . . . . . Specifying Return Data Types . . . . . . . . . . Returning the Value . . . . . . . . . . . . . . Returning More Than One Set of Values from a Procedure Exception Handling . . . . . . . . . . . . Trapping an Error and Recovering . . . . . . Scope of Control of an ON EXCEPTION Statement User-Generated Exceptions. . . . . . . . . Simulating SQL Errors . . . . . . . . . Using RAISE EXCEPTION to Exit Nested Code Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12-28 12-28 12-28 12-29 12-29
. . . . . . 12-31 . . . . . . 12-31 . . . . . . 12-32 . . . . . . 12-34 . . . . . . 12-34 . . . . . . 12-35 . . . . . . 12-36
12-2
ou can write procedures using SQL and some additional statements belonging to the Stored Procedure Language (SPL), and store this procedure in the database. These stored procedures are effective tools for controlling SQL activity. This chapter provides instruction on how to write stored procedures. To help you learn how to write them, examples of working stored procedures are provided. The syntax for each SPL statement is described in Chapter 1 of the Informix Guide to SQL: Syntax. Accompanying the syntax for each statement are usage notes and examples pertinent to that statement.
Introduction to Stored Procedures and SPL

To SQL, a stored procedure is a user-dened function. Anyone who has the Resource privilege on a database can create a stored procedure. Once the stored procedure is created, it is stored in an executable format in the database as an object of the database. You can use stored procedures to perform any function you can perform in SQL as well as to expand what you can accomplish with SQL alone. You write a stored procedure using SQL and SPL statements. SPL statements can be used only inside the CREATE PROCEDURE and CREATE PROCEDURE FROM statements. The CREATE PROCEDURE statement is available with DB-Access, and the CREATE PROCEDURE and CREATE PROCEDURE FROM statements are available with SQL APIs such as INFORMIX-ESQL/C and INFORMIX-ESQL/COBOL. The CREATE PROCEDURE FROM statement is also available with INFORMIX-4GL and NewEra.
Creating and Using Stored Procedures 12-3
What You Can Do with Stored Procedures
What You Can Do with Stored Procedures

You can accomplish a wide range of objectives with stored procedures, including improving database performance, simplifying writing applications, and limiting or monitoring access to data. Because a stored procedure is stored in an executable format, you can use it to execute frequently repeated tasks to improve performance. Executing a stored procedure rather than straight SQL code allows you to bypass repeated parsing, validity checking, and query optimization. Because a stored procedure is an object in the database, it is available to every application running on the database. Several applications can use the same stored procedure, so development time for applications is reduced. You can write a stored procedure to be run with the DBA privilege by a user who does not have the DBA privilege. This allows you to limit and control access to data in the database. Alternatively, a stored procedure can monitor the users who access certain tables or data. (See Controlling Access to Data Using Stored Procedures on page 10-16 for a discussion of this topic.)
Relationship Between SQL and a Stored Procedure

You can call a procedure within data-manipulation SQL statements and issue SQL statements within a procedure. See Chapter 1 of the Informix Guide to SQL: Syntax for a complete list of data manipulation SQL statements. You use a stored procedure within a data-manipulation SQL statement to supply values to that statement. For example, you can use a procedure to perform the following actions:
s s
Supply values to be inserted into a table Supply a value that makes up part of a condition clause in a SELECT, DELETE, or UPDATE statement
12-4
These are two possible uses of a procedure within a data manipulation statement, but others exist. In fact, any expression within a data manipulation SQL statement can consist of a procedure call. You can also issue SQL statements within a stored procedure to hide those SQL statements from a database user. Rather than having all users learn how to use SQL, one experienced SQL user can write a stored procedure to encapsulate an SQL activity and let others know that the procedure is stored in the database so they can execute it.

To write a stored procedure, put the SQL statements that you want run as part of the procedure inside the statement block in a CREATE PROCEDURE statement. You can use SPL statements to control the ow of the operation within the procedure. SPL statements include IF, FOR, and others and are described in the Informix Guide to SQL: Syntax. The CREATE PROCEDURE and CREATE PROCEDURE FROM statements are also described in Chapter 1 of the Informix Guide to SQL: Syntax.
Creating a Procedure Using DB-Access
Creating a Procedure Using DB-Access

To create a stored procedure using DB-Access, issue the CREATE PROCEDURE statement, including all the statements that are part of the procedure in the statement block. For example, to create a procedure that reads a customer address, use a statement such as the one in Figure 12-1.
CREATE PROCEDURE read_address (lastname CHAR(15)) -- one argument RETURNING CHAR(15), CHAR(15), CHAR(20), CHAR(15),CHAR(2), CHAR(5); -- 6 items DEFINE DEFINE DEFINE DEFINE p_lname,p_fname, p_city CHAR(15); --define each procedure variable p_add CHAR(20); p_state CHAR(2); p_zip CHAR(5);
Figure 12-1 Procedure that reads from the customer table
SELECT fname, address1, city, state, zipcode INTO p_fname, p_add, p_city, p_state, p_zip FROM customer WHERE lname = lastname; RETURN p_fname, lastname, p_add, p_city, p_state, p_zip; --6 items END PROCEDURE DOCUMENT 'This procedure takes the last name of a customer as', --brief --description 'its only argument. It returns the full name and address of', 'the customer.' WITH LISTING IN '/acctng/test/listfile' -- compile-time warnings go here ; -- end of the procedure read_address
Creating a Procedure in a Program

To create a stored procedure using NewEra, INFORMIX-4GL, or an SQL API, put the text of the CREATE PROCEDURE statement in a le. Use the CREATE PROCEDURE FROM statement and refer to that le to compile the procedure. For example, to create a procedure to read a customer name, you can use a statement such as the one in Figure 12-1 and store it in a le. If the le is named read_add_source, the following statement compiles the read_address procedure:
CREATE PROCEDURE FROM 'read_add_source';
12-6
Commenting and Documenting a Procedure
Figure 12-2 shows how the previous SQL statement looks in an ESQL/C program.
/* This program creates whatever procedure is in * * the file 'read_add_source'. */ #include <stdio.h> EXEC SQL include sqlca; EXEC SQL include sqlda; EXEC SQL include datetime; /* Program to create a procedure from the pwd */ main() { EXEC SQL database play; EXEC SQL create procedure from 'read_add_source'; }
Figure 12-2 SQL statement that compiles and stores the read_address procedure in an ESQL/C program
Commenting and Documenting a Procedure

Observe that the read_address procedure in Figure 12-2 includes comments and a DOCUMENT clause. The comments are incorporated into the text of the procedure. Any characters following a double hyphen (--) are considered to be a comment. The double hyphen can be used anywhere within a line. The text in the DOCUMENT clause should give a summary of the procedure. You can extract this text by querying the sysprocbody system catalog table. See Looking at the Procedure Documentation on page 12-11 for more information about reading the DOCUMENT clause.
Diagnosing Compile-Time Errors

When you issue a CREATE PROCEDURE or CREATE PROCEDURE FROM statement, the statement fails if a syntax error occurs in the body of the procedure. The database server stops processing the text of the procedure and returns the location of the error.
Diagnosing Compile-Time Errors Finding Syntax Errors in a Procedure Using DB-Access

If a procedure created using DB-Access has a syntax error, when you choose the Modify option of the SQL menu, the cursor sits on the line containing the offending syntax.
Finding Syntax Errors in a Procedure Using an SQL API

If a procedure created using an SQL API has a syntax error, the CREATE PROCEDURE statement fails and sets SQLCA and SQLSTATE values. The database server sets the SQLCODE eld of the SQLCA to a negative number and sets the fth element of the SQLERRD array to the character offset into the le. The particular elds of the SQLCA for each product are shown in the following table:
ESQL/C sqlca.sqlcode SQLCODE sqlca.sqlerrd[4] ESQL/FORTRAN sqlcod sqlca.sqlerr(5) ESQL/COBOL SQLCODE OF SQLCA SQLERRD[5] OF SQLCA
In case of syntax error, the database server sets SQLSTATE to 42000.
12-8
Looking at Compile-Time Warnings
Figure 12-3 shows how to trap for a syntax error when you are creating a procedure. It also shows how to display a message and character position where the error occurred.
#include <stdio.h> EXEC SQL include sqlca; EXEC SQL include sqlda; EXEC SQL include datetime; /* Program to create a procedure from procfile in pwd */ main() { long char_num; EXEC SQL database play; EXEC SQL create procedure from 'procfile'; if (sqlca.sqlcode != 0 ) { printf("\nsqlca.sqlcode = %ld\n", sqlca.sqlcode); char_num = sqlca.sqlerrd[4]; printf("\nError in creating read_address. Check character position %ld\n", char_num); } . . .
Figure 12-3 Checking for failure when creating a procedure using ESQL/C
In Figure 12-3, if the CREATE PROCEDURE FROM statement fails, the program displays a message in addition to the character position at which the syntax error occurred.
Looking at Compile-Time Warnings

If the database server detects a potential problem but the procedure is syntactically correct, the database server generates a warning and places it in a listing le. You can examine this le to check for potential problems before executing the procedure.
Generating the Text or Documentation
To obtain the listing of compile-time warnings for your procedure, use the WITH LISTING IN clause in your CREATE PROCEDURE statement, as shown in the following example:
CREATE PROCEDURE read_address (lastname CHAR(15)) -- one argument RETURNING CHAR(15), CHAR(15), CHAR(20), CHAR(15), CHAR(2), CHAR(5); -- 6 items . . . WITH LISTING IN '/acctng/test/listfile' -- compile-time warnings go here ; -- end of the procedure read_address
If you are working on a network, the listing le is created on the computer where the database resides. If you provide an absolute pathname and lename for the le, the le is created where you specify. If you provide a relative pathname for the listing le, the le is created in your home directory on the computer where the database resides. (If you do not have a home directory, the le is created in the root directory.) After you create the procedure, you can view the le specied in the WITH
LISTING IN clause to see the warnings it contains.
Generating the Text or Documentation

Once you create the procedure, it is stored in the sysprocbody system catalog table. The sysprocbody system catalog table contains the executable procedure as well as the text of the original CREATE PROCEDURE statement and the documentation text.
Looking at the Procedure Text

To generate the text of the procedure, select the data column from the sysprocbody system catalog table. The following SELECT statement reads the read_address procedure text:
SELECT data FROM informix.sysprocbody WHERE datakey = 'T' -- find text lines AND procid = (SELECT procid FROM informix.sysprocedures WHERE informix.sysprocedures.procname = 'read_address')
12-10
Executing a Procedure Looking at the Procedure Documentation

If you want to view only the documenting text of the procedure, use the following SELECT statement to read the documentation string. The documentation lines found in the following example are those in the DOCUMENT clause of the CREATE PROCEDURE statement.
SELECT data FROM informix.sysprocbody WHERE datakey = 'D' -- find documentation lines AND procid = (SELECT procid FROM informix.sysprocedures WHERE informix.sysprocedures.procname = 'read_address')
Executing a Procedure
You can execute a procedure in several ways. You can use the SQL statement EXECUTE PROCEDURE or either the LET or CALL SPL statement. In addition, you can dynamically execute procedures, as described in Executing a Stored Procedure Dynamically on page 12-13. The read_address procedure returns the full name and address of a customer. To run read_address on a customer called Putnum using EXECUTE PROCEDURE, enter the following statement:
EXECUTE PROCEDURE read_address ('Putnum');
Executing a Procedure
The read_address procedure returns values; therefore, if you are executing a procedure from an SQL API, INFORMIX-4GL, NewEra, or from another procedure, you must use an INTO clause with host variables to receive the data. For example, executing the read_address procedure in an ESQL/C program is accomplished with the code segment shown in Figure 12-4.
#include <stdio.h> EXEC SQL include sqlca; EXEC SQL include sqlda; EXEC SQL include datetime; /* Program to execute a procedure in the database named main() { EXEC SQL BEGIN DECLARE SECTION; char lname[16], fname[16], address[21]; char city[16], state[3], zip[6]; EXEC SQL END DECLARE SECTION; EXEC SQL connect to 'play'; EXEC SQL EXECUTE PROCEDURE read_address ('Putnum') INTO :lname, :fname, :address, :city, :state, :zip; if (sqlca.sqlcode != 0 ) printf("\nFailure on execute"); }
'play'
*/
Figure 12-4 Executing a procedure using ESQL/C
If you are executing a procedure within another procedure, you can use the SPL statements CALL or LET to run the procedure. To use the CALL statement with the read_address procedure, you can use the code shown in Figure 12-5.
CREATE PROCEDURE address_list () DEFINE p_lname, p_fname, p_city CHAR(15); DEFINE p_add CHAR(20); DEFINE p_state CHAR(2); DEFINE p_zip CHAR(5); . . . CALL read_address ('Putnum') RETURNING p_fname, p_lname, p_add, p_city, p_state, p_zip; . . . -- use the returned data some way END PROCEDURE;
Figure 12-5 Calling a procedure inside another procedure with the CALL statement
12-12
Executing a Stored Procedure Dynamically
Figure 12-6 provides an example of using the LET statement to assign values to procedural variables through a procedure call.
CREATE PROCEDURE address_list () DEFINE p_lname, p_fname, p_city CHAR(15); DEFINE p_add CHAR(20); DEFINE p_state CHAR(2); DEFINE p_zip CHAR(5); . . . LET p_fname, p_lname,p_add, p_city, p_state, p_zip = read_address ('Putnum'); . . . -- use the returned data some way END PROCEDURE;
Figure 12-6 Assigning values from a procedure call with a LET statement
Executing a Stored Procedure Dynamically

You can prepare an EXECUTE PROCEDURE statement in conjunction with the ALLOCATE DESCRIPTOR and GET DESCRIPTOR statements in an ESQL/C program. Parameters to the stored procedure can be passed in the same manner as the SELECT statement and may be passed at run time or compile time. For a detailed example of executing a stored procedure dynamically, see Chapter 10 of the INFORMIX-ESQL/C Programmers Manual. For information about dynamic SQL and using a prepared SELECT statement, see Chapter 5, Programming with SQL.
Debugging a Procedure
Once you successfully create and run a procedure, you can encounter logical errors. If logical errors are in the procedure, use the TRACE statement to help nd them. You can trace the values of the following procedural entities:
s s s s s
Variables Procedure arguments Return values

SQL error codes ISAM error codes
To generate a listing of traced values, rst use the SQL statement SET DEBUG FILE to name the le that is to contain the traced output. When you create your procedure, include the TRACE statement in one of its forms. The following ways specify the form of TRACE output:
TRACE ON
TRACE PROCEDURE TRACE expression
traces all statements except SQL statements. The contents of variables are printed before being used. Procedure calls and returned values are also traced. traces only the procedure calls and returned values. prints a literal or an expression. If necessary, the value of the expression is calculated before being sent to the le.
Figure 12-7 shows how you can use the TRACE statement with a version of the read_address procedure. Several SPL statements shown in this example have not been discussed, but the entire example demonstrates how the TRACE statement can help you monitor execution of the procedure.
CREATE PROCEDURE read_many (lastname CHAR(15)) RETURNING CHAR(15), CHAR(15), CHAR(20), CHAR(15),CHAR(2), CHAR(5); DEFINE DEFINE DEFINE DEFINE DEFINE p_lname,p_fname, p_city CHAR(15); p_add CHAR(20); p_state CHAR(2); p_zip CHAR(5); lcount, i INT;
Figure 12-7 Using the TRACE statement to monitor execution of a procedure
LET lcount = 1; TRACE ON; -- Every expression will be traced from here on TRACE 'Foreach starts';-- A trace statement with a literal FOREACH SELECT fname, lname, address1, city, state, zipcode INTO p_fname, p_lname, p_add, p_city, p_state, p_zip FROM customer WHERE lname = lastname RETURN p_fname, p_lname, p_add, p_city, p_state, p_zip WITH RESUME; LET lcount = lcount + 1; -- count of returned addresses END FOREACH; TRACE 'Loop starts'; -- Another literal FOR i IN (1 TO 5) BEGIN RETURN i , i+1, i*i, i/i, i-1,i with resume; END END FOR; END PROCEDURE;
12-14
Each time you execute the traced procedure, entries are added to the le you specied using the SET DEBUG FILE statement. To see the debug entries, view the output le using any text editor. The following list contains some of the output generated by the procedure in Figure 12-7 on page 12-14. Next to each traced statement is an explanation of its contents.
TRACE ON
echoed TRACE ON statement. traced expression, in this case, the literal string Foreach starts. start select cursor notication that a cursor is opened to handle a FOREACH loop. select cursor iteration notication of the start of each iteration of the select cursor. expression: (+lcount, 1) the encountered expression, (lcount+1) evaluates to 2. let lcount = 2 each LET statement is echoed with the value.
TRACE Foreach starts
Re-creating a Procedure
If a procedure exists in a database, you must drop it explicitly using the DROP PROCEDURE statement before you can create another procedure with the same name. If you debug your procedure and attempt to use the CREATE PROCEDURE statement with the same procedure name again, the attempt fails unless you rst drop the existing procedure from the database.
Privileges on Stored Procedures
Privileges on Stored Procedures

A stored procedure resides in the database in which it was created. As with other database objects, you need appropriate privileges to create a stored procedure. In addition, you need appropriate privileges to execute a stored procedure. Two types of stored procedures exist in a database: DBA-privileged and owner-privileged. When you create the procedure, you specify which type it is. You need different privileges to create and execute these two types of procedures. The differences are described in the sections that follow and are summarized in Figure 12-8.
Figure 12-8 Differences between DBA-privileged and owner-privileged procedures
DBA-privileged procedure Can be created by: Users having the Execute privilege by default: Any user with the DBA privilege Any user with the DBA privilege Owner-privileged procedure Any user with at least the Resource privilege Not ANSI-compliant: Public (any user with Connect database privilege) ANSI-compliant: The procedure owner and any user with the DBA privilege Privileges the procedure owner or DBA must grant another user to enable that user to run a procedure: Execute privilege Execute privilege and privileges on underlying objects. If owner has privileges on underlying objects with the GRANT WITH option, only the Execute privilege is required
12-16
Privileges Necessary at Creation
Privileges Necessary at Creation

Only users who have the DBA privilege can create a DBA-privileged procedure. To create an owner-privileged procedure, you need to have at least the Resource privilege. See Chapter 10, Granting and Limiting Access to Your Database..
Privileges Necessary at Execution

To run a procedure, you always need the Execute privilege for that procedure or DBA database privileges. Depending on whether the procedure is a DBAmode procedure and if the database is ANSI-compliant, certain privileges are granted to users implicitly by the database server. If the procedure is owner-privileged, the database server grants the Execute privilege to PUBLIC. If the database is ANSI-compliant, the database server grants only the Execute privilege to the owner and users with DBA status. If the procedure is DBA-privileged, the database server grants the Execute privilege to all users having the DBA privilege.
Owner-Privileged Procedures
When you execute an owner-privileged procedure, the database server checks the existence of any referenced objects. In addition, the database server veries that you have the necessary privileges on the referenced objects. If you execute a procedure that only references objects that you own, no privilege conicts occurs. If you do not own the referenced objects and you execute a procedure that contains SELECT statements, for example, you need the Select privilege on the appropriate tables to run the procedure without generating errors. If the owner has the necessary privileges with the WITH GRANT option, those privileges are automatically conferred to you when the owner issues a GRANT EXECUTE statement.
Privileges Necessary at Execution
Unqualied objects created in the course of the procedure are owned by the owner of the procedure, not the user running the procedure. For example, the following example shows lines in an owner-privileged stored procedure that create two tables. If this procedure is owned by tony and a user marty runs the procedure, the rst table, gargantuan, is owned by tony. The second table, tiny, is owned by libby. The table gargantuan is an unqualied name; therefore, tony owns the table gargantuan. The table tiny is qualied by the owner libby, so libby owns the table tiny.
CREATE PROCEDURE tryit() . . . CREATE TABLE gargantuan (col1 INT, col2 INT, col3 INT); CREATE TABLE libby.tiny (col1 INT, col2 INT, col3 INT); END PROCEDURE;
DBA-Privileged Procedures
When you execute a DBA-privileged procedure, you assume the privileges of a DBA for the duration of the procedure. A DBA-privileged procedure acts as if the user running the procedure is rst granted DBA privilege, then executes each statement of the procedure manually, and nally has DBA privilege revoked. Objects created in the course of running a DBA procedure are owned by the user running the procedure, unless the data-denition statement in the procedure explicitly names the owner to be someone else.
Privileges and Nested Procedures

DBA-privileged status is not inherited by a called procedure. For example, if a DBA-privileged procedure executes an owner-privileged procedure, the owner-privileged procedure does not run as a DBA procedure. If an ownerprivileged procedure calls a DBA-privileged procedure, the statements within the DBA-privileged procedure execute as they would within any DBA-privileged procedure.
12-18
Revoking Privileges
Revoking Privileges
The owner of a procedure can revoke the Execute privilege from a user. If a user loses the Execute privilege on a procedure, the Execute privilege is also revoked from all users who were granted the Execute privilege by that user.
Variables and Expressions

This section discusses how to dene and use variables in SPL. The differences between SPL and SQL expressions also are covered here.
Variables
You can use a variable in a stored procedure in several ways. You can use a variable in a database query or other SQL statement wherever a constant is expected. You can use a variable with SPL statements to assign and calculate values, keep track of the number of rows returned from a query, and execute a loop as well as handle other tasks. The value of a variable is held in memory; the variable is not a database object. Hence, rolling back a transaction does not restore values of procedural variables.
Format of Variables
A variable follows the rules of an SQL identier. (See Chapter 1 of the Informix Guide to SQL: Syntax.) Once you dene a variable, you can use it anywhere in the procedure as appropriate. If you are using an SQL API, you do not have to set off the variable with a special symbol (unlike host variables in an SQL API).
Variables Global and Local Variables

You can dene a variable to be either local or global. A variable is local by default. The following denitions describe the differences between the two types: Local A local variable is available only within the procedure in which it is dened. Local variables do not allow a default value to be assigned at compile time. A global variable is available to other procedures run by the same user session in the same database. The values of global variables are stored in memory. The global environment is the memory used by all the procedures run within a given session on a given database server, such as all procedures run by an SQL API or in a DB-Access session. The values of the variables are lost when the session ends. Global variables require a default value to be assigned at compile time. The rst denition of a global variable puts the variable into the global environment. Subsequent denitions of the same variable, in different procedures, simply bind the variable to the global environment.
Global
Dening Variables
You dene variables using the DEFINE statement. If you list a variable in the argument list of a procedure, the variable is dened implicitly, and you do not need to dene it formally with the DEFINE statement. You must assign a value, which may be null, to a variable before you can use it.
12-20
Variables Data Types for Variables

You can dene a variable as any of the data types available for columns in a table except SERIAL. The following example shows several cases of dened procedural variables:
DEFINE x INT; DEFINE name CHAR(15); DEFINE this_day DATETIME YEAR TO DAY ;
If you dene a variable for TEXT or BYTE data, the variable does not actually contain the data; instead, it serves as a pointer to the data. However, use this procedural variable as you would use any other procedural variable. When you dene a TEXT or BYTE variable, you must use the word REFERENCES, which emphasizes that these variables do not contain the data; they simply reference the data. The following example shows the denition of a TEXT and a BYTE variable:
DEFINE ttt REFERENCES TEXT; DEFINE bbb REFERENCES BYTE;
Using Subscripts with Variables

You can use subscripts with variables having CHAR, VARCHAR, NCHAR, NVARCHAR, BYTE or TEXT data types, just as you can with SQL column names. The subscripts indicate the starting and ending character positions of the variable. Subscripts must always be constants. You cannot use variables as subscripts. The following example illustrates the usage:
DEFINE name CHAR(15); LET name[4,7] = 'Ream'; SELECT fname[1,3] INTO name[1,3] FROM customer WHERE lname = 'Ream';
The portion of the variable contents that is delimited by the two subscripts is referred to as a substring.
Variables Scope of Variables

A variable is valid within the statement block in which it is dened. It is valid within statement blocks nested within that statement block as well, unless it is masked by a redenition of a variable with the same name. In the beginning of the procedure in Figure 12-9, the integer variables x, y, and z are dened and initialized. The BEGIN and END statements mark a nested statement block in which the integer variables x and q are dened as well as the CHAR variable z. Within the nested block, the redened variable x masks the original variable x. After the END statement, which marks the end of the nested block, the original value of x is accessible again.
CREATE PROCEDURE scope() DEFINE x,y,z INT; LET x = 5; LET y = 10; LET z = x + y; --z is 15 BEGIN DEFINE x, q INT; DEFINE z CHAR(5); LET x = 100; LET q = x + y; -- q = 110 LET z = 'silly'; -- z receives a character value END LET y = x; -- y is now 5 LET x = z; -- z is now 15, not 'silly' END PROCEDURE;
Figure 12-9 Masking of variables with nested statement blocks
Variable/Keyword Ambiguity
If you dene a variable as a keyword, ambiguities can occur. The following rules for identiers help you avoid ambiguities for variables, procedure names, and system function names:
s s
Dened variables take the highest precedence. Procedures dened as such in a DEFINE statement take precedence over SQL functions.
SQL functions take precedence over procedures that exist but are not identied as procedures in a DEFINE statement.
In some cases, you must change the name of the variable. For example, you cannot dene a variable with the name count or max, because these are the names of aggregate functions. Refer to Chapter 1 of the Informix Guide to SQL: Syntax for a list of the keywords that can be used ambiguously.
Variables Variables and Column Names

If you use the same identier for a procedural variable as you use for a column name, the database server assumes that each instance of the identier is a variable. Qualify the column name with the table name to use the identier as a column name. In the following example, the procedure variable lname is the same as the column name. In the following SELECT statement, customer.lname is a column name and lname is a variable name:
CREATE PROCEDURE table_test() DEFINE lname CHAR(15); LET lname = 'Miller'; . . . SELECT customer.lname FROM customer INTO lname WHERE customer_num = 502; . . .
Variables and SQL Functions

If you use the same identier for a procedural variable as for an SQL function, the database server assumes that an instance of the identier is a variable and disallows the use of the SQL function. You cannot use the SQL function within the block of code in which the variable is dened. The following example shows a block within a procedure in which the variable called user is dened. This denition disallows the use of the USER function in the BEGIN...END block.
CREATE PROCEDURE user_test() DEFINE name CHAR(10); DEFINE name2 CHAR(10); LET name = user; -- the SQL function BEGIN DEFINE user CHAR(15); -- disables user function LET user = 'Miller'; LET name = user; -- assigns 'Miller' to variable name END . . . LET name2 = user; -- SQL function again
SPL Expressions Procedure Names and SQL Functions

For information about ambiguities between procedure names and SQL function names, see the Informix Guide to SQL: Syntax.
SPL Expressions
You can use any SQL expression in a stored procedure except for an aggregate expression. The complete syntax and notes for SQL expressions are described in Chapter 1 of the Informix Guide to SQL: Syntax. The following examples contain SQL expressions:
var1 var1 + var2 + 5 read_address('Miller') read_address(lastname = 'Miller') get_duedate(acct_num) + 10 UNITS DAY fname[1,5] || ''|| lname '(415)' || get_phonenum(cust_name)
Assigning Values to Variables

You can assign a value to a procedure variable in the following ways:
s s s
Using a LET statement Using a SELECT...INTO statement Using a CALL statement with a procedure that has a RETURNING clause Using an EXECUTE PROCEDURE...INTO statement
Use the LET statement to assign a value to one or more variables. The following example illustrates several forms of the LET statement:
LET a = b + a; LET a, b = c, d; LET a, b = (SELECT fname, lname FROM customer WHERE customer_num = 101); LET a, b = read_name(101);
12-24
Program Flow Control
Use the SELECT statement to assign a value directly from the database to a variable. The statement in the following example accomplishes the same task as the third LET statement in the previous example:
SELECT fname, lname into a, b FROM customer WHERE customer_num = 101
Use the CALL or EXECUTE PROCEDURE statements to assign values returned by a procedure to one or more procedural variables. Both statements in the following example return the full address from the procedure read_address into the specied procedural variables:
EXECUTE PROCEDURE read_address('Smith') INTO p_fname, p_lname, p_add, p_city, p_state, p_zip; CALL read_address('Smith') RETURNING p_fname, p_lname, p_add, p_city, p_state, p_zip;
Program Flow Control

SPL contains several statements that enable you to control the ow of your
stored procedure and to make decisions based on data obtained at run time. These program-ow-control statements are described briey in this section. Their syntax and complete descriptions are provided in Chapter 2 of the Informix Guide to SQL: Syntax.
Branching
Use an IF statement to form a logic branch in a stored procedure. An IF statement rst evaluates a condition and, if the condition is true, the statement block contained in the THEN portion of the statement is executed. If the condition is not true, execution falls through to the next statement, unless the IF statement includes an ELSE clause or ELIF (else if) clause. Figure 12-10 on page 12-26 shows an example of an IF statement.
Looping
CREATE PROCEDURE str_compare (str1 CHAR(20), str2 CHAR(20)) RETURNING INT; DEFINE result INT; IF str1 > str2 THEN result = 1; ELIF str2 > str1 THEN result = -1; ELSE result = 0; END IF RETURN result; END PROCEDURE; -- str_compare
Figure 12-10 Using an IF statement
Looping
Three methods of looping exist in SPL, accomplished with one of the following statements:
FOR FOREACH
initiates a controlled loop. Termination is guaranteed. allows you to select and manipulate more than one row from the database. It declares and opens a cursor implicitly. initiates a loop. Termination is not guaranteed.
WHILE
Four ways exist to leave a loop, which can accomplished with one of the following statements:
CONTINUE EXIT RETURN
skips the remaining statements in the present, identied loop and starts the next iteration of that loop. exits The present, identied loop. Execution resumes at the rst statement after the loop. exits the procedure. If a return value is specied, that value is returned upon exit. the body of the loop.
RAISE EXCEPTION exits the loop if the exception is not trapped (caught) in
See Chapter 2 of the Informix Guide to SQL: Syntax for more information concerning the syntax and use of these statements.
12-26
Function Handling
Function Handling
You can call procedures as well as run operating system commands from within a procedure.
Calling Procedures Within a Procedure

Use a CALL statement or the SQL statement EXECUTE PROCEDURE to execute a procedure from a procedure. Figure 12-11 shows a call to the read_name procedure using a CALL statement.
CREATE PROCEDURE call_test() RETURNING CHAR(15), CHAR(15); DEFINE fname, lname CHAR(15); CALL read_name('Putnum') RETURNING fname, lname; IF fname = 'Eileen' THEN RETURN 'Jessica', lname; ELSE RETURN fname, lname; END IF END PROCEDURE;
Figure 12-11 Calling a procedure with a CALL statement
Running an Operating System Command from Within a Procedure

Use the SYSTEM statement to execute a system call from a procedure. Figure 12-12 shows a call to the echo command.
CREATE DBA PROCEDURE delete_customer(cnum INT) DEFINE username CHAR(8); DELETE FROM customer WHERE customer_num = cnum; IF username = 'acctclrk' THEN SYSTEM 'echo ''Delete from customer by acctclrk'' >> /mis/records/updates' ; END IF END PROCEDURE; -- delete_customer
Figure 12-12 Making a system call from a procedure with a SYSTEM statement
Recursively Calling a Procedure

You can call a procedure from itself. No restrictions apply on calling a procedure recursively.
Passing Information into and out of a Procedure
Passing Information into and out of a Procedure

When you create a procedure, you determine whether it expects information to be passed to it by specifying an argument list. For each piece of information that the procedure expects, you specify one argument and the data type of that argument. For example, if a procedure needs to have a single piece of integer information passed to it, you can provide a procedure heading as shown in the following example:
CREATE PROCEDURE safe_delete(cnum INT)
Returning Results
A procedure that returns one or more values must contain two lines of code to accomplish the transfer of information: one line to state the data types that are going to be returned, and one line to return the values explicitly.
Specifying Return Data Types

Immediately after you specify the name and input parameters of your procedure, you must include a RETURNING clause with the data type of each value you expect to be returned. The following example shows the header of a procedure (name, parameters, and RETURNING clause) that expects one integer as input and returns one integer and one 10-byte character value:
CREATE PROCEDURE get_call(cnum INT) RETURNING INT, CHAR(10);
12-28
Returning Results Returning the Value

Once you use the RETURNING clause to indicate the type of values that are to be returned, you can use the RETURN statement at any point in your procedure to return the same number and data types as listed in the RETURNING clause. The following example shows how you can return information from the get_call procedure:
CREATE PROCEDURE get_call(cnum INT) RETURNING INT, CHAR(10); DEFINE ncalls INT; DEFINE o_name CHAR(10); . . . RETURN ncalls, o_name; . . . END PROCEDURE;
If you neglect to include a RETURN statement, you do not get an error message at compile time.
Returning More Than One Set of Values from a Procedure

If your procedure performs a select that can return more than one row from the database or if you return values from inside a loop, you must use the WITH RESUME keywords in the RETURN statement. Using a RETURN...WITH RESUME statement causes the value or values to be returned to the calling program or procedure. After the calling program receives the values, execution returns to the statement immediately following the RETURN...WITH RESUME statement.
Returning Results
Figure 12-13 is an example of a cursory procedure. It returns values from a FOREACH loop and a FOR loop. This procedure is called a cursory procedure because it contains a FOREACH loop.
CREATE PROCEDURE read_many (lastname CHAR(15)) RETURNING CHAR(15), CHAR(15), CHAR(20), CHAR(15),CHAR(2), CHAR(5); DEFINE DEFINE DEFINE DEFINE DEFINE DEFINE p_lname,p_fname, p_city CHAR(15); p_add CHAR(20); p_state CHAR(2); p_zip CHAR(5); lcount INT ; i INT ;
Figure 12-13 Procedure that returns values from a FOREACH loop and a FOR loop
LET lcount = 0; TRACE ON; CREATE VIEW myview AS SELECT * FROM customer; TRACE 'Foreach starts'; FOREACH SELECT fname, lname, address1, city, state, zipcode INTO p_fname, p_lname, p_add, p_city, p_state, p_zip FROM customer WHERE lname = lastname RETURN p_fname, p_lname, p_add, p_city, p_state, p_zip WITH RESUME; LET lcount = lcount +1; END FOREACH; FOR i IN (1 TO 5) BEGIN RETURN 'a', 'b', 'c', 'd', 'e' WITH RESUME; END END FOR; END PROCEDURE;
When you execute this procedure, it returns the name and address for each person with the specied last name. It also returns a sequence of letters. The calling procedure or program must be expecting multiple returned values, and it must use a cursor or a FOREACH statement to handle the multiple returned values.
12-30
Exception Handling
Exception Handling
You can trap any exception (or error) returned by the database server to your procedure, or raised by your procedure, with the ON EXCEPTION statement. The RAISE EXCEPTION statement lets you generate an exception within your procedure.
Trapping an Error and Recovering

The ON EXCEPTION statement provides a mechanism to trap any error. To trap an error, enclose a group of statements in a statement block and precede the statement block with an ON EXCEPTION statement. If an error occurs in the block that follows the ON EXCEPTION statement, you can take recovery action. Figure 12-14 shows an example of an ON EXCEPTION statement within a BEGIN...END block.
BEGIN DEFINE c INT; ON EXCEPTION IN ( -206, -- table does not exist -217 -- column does not exist ) SET err_num IF err_num = -206 THEN CREATE TABLE t (c INT); INSERT INTO t VALUES (10); -- continue after the insert statement ELSE ALTER TABLE t ADD(d INT); LET c = (SELECT d FROM t); -- continue after the select statement. END IF END EXCEPTION WITH RESUME INSERT INTO t VALUES (10); LET c = (SELECT d FROM t); END -- will fail if t does not exist -- will fail if d does not exist
Figure 12-14 An ON EXCEPTION statement within a BEGIN...END block
Scope of Control of an ON EXCEPTION Statement
When an error occurs, the SPL interpreter searches for the innermost ON EXCEPTION declaration that traps the error. Note that the rst action after trapping the error is to reset the error. When execution of the error action code is complete, and if the ON EXCEPTION declaration that was raised included the WITH RESUME keywords, execution resumes automatically with the statement following the statement that generated the error. If the ON EXCEPTION declaration did not include the WITH RESUME keywords, execution exits the current block completely.

An ON EXCEPTION statement is valid for the statement block that follows the ON EXCEPTION statement, all the statement blocks nested within that following statement block, and all the statement blocks that follow the ON EXCEPTION statement. It is not valid in the statement block that contains the ON EXCEPTION statement. The pseudocode in Figure 12-15 on page 12-33 shows where the exception is valid within the procedure. That is, if error 201 occurs in any of the indicated blocks, the action labeled a201 occurs.
12-32
CREATE PROCEDURE scope() DEFINE i INT; . . . BEGIN -- begin statement block . . . ON EXCEPTION IN (201) -- do action a201 END EXCEPTION BEGIN -- statement block aa -- do action, a201 valid END BEGIN -- statement block bb -- do action, a201 valid END WHILE i < 10 -- do something, a201 is END WHILE
Figure 12-15 Pseudocode showing the ON EXCEPTION statement is valid within a procedure
here here valid here
END BEGIN -- begin statement block B -- do something -- a201 is NOT valid here END END PROCEDURE;
User-Generated Exceptions
User-Generated Exceptions
You can generate your own error using the RAISE EXCEPTION statement, as shown in the following pseudocode example. In this example, the ON EXCEPTION statement uses two variables, esql and eisam, to hold the error numbers returned by the database server. If an error occurs and the SQL error number is -206, the action dened in the IF clause is taken. If any other SQL error is caught, it is passed out of this BEGIN...END block to the block that contains this block.
BEGIN ON EXCEPTION SET esql, eisam -- trap all errors IF esql = -206 THEN -- table not found -- recover somehow ELSE RAISE exception esql, eisam ; -- pass the error up END IF END EXCEPTION -- do something END
Simulating SQL Errors

You can generate errors to simulate SQL errors, as shown in the following example. Here, if the user is pault, then the stored procedure acts as if that user has no update privileges, even if he really does have that privilege.
BEGIN IF user = 'pault' THEN RAISE EXCEPTION -273; END IF END
-- deny Paul update privilege
12-34
User-Generated Exceptions Using RAISE EXCEPTION to Exit Nested Code

You can use the RAISE EXCEPTION statement to break out of a deeply nested block, as shown in Figure 12-16. If the innermost condition is true (if aa is negative), then the exception is raised and execution jumps to the code following the END of the block. In this case, execution jumps to the TRACE statement.
BEGIN ON EXCEPTION IN (1) END EXCEPTION WITH RESUME -- do nothing significant (cont BEGIN FOR i IN (1 TO 1000) FOREACH select ..INTO aa FROM t IF aa < 0 THEN RAISE EXCEPTION 1 ; -- emergency exit END IF END FOREACH END FOR RETURN 1; END --do something; -- emergency exit to -- this statement. TRACE 'Negative value returned'; RETURN -10; END
Figure 12-16 Breaking out of nested loop with a RAISE EXCEPTION statement
Remember that a BEGIN...END block is a single statement. When an error occurs somewhere inside a block and the trap is outside the block, when execution resumes, the rest of the block is skipped and execution resumes at the next statement. Unless you set a trap for this error somewhere in the block, the error condition is passed back to the block that contains the call and back to any blocks that contain the block. If no ON EXCEPTION statement exists that is set to handle the error, execution of the procedure stops, creating an error for the program or procedure that is executing the procedure.
Summary
Summary
Stored procedures provide many opportunities for streamlining your database process, including enhanced database performance, simplied applications, and limited or monitored access to data. See the Informix Guide to SQL: Syntax for syntax diagrams of SPL statements.
12-36
Chapter
13
. . . . . . 13-3 13-4 13-5 13-5 13-6 13-7
When to Use Triggers .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
How to Create a Trigger . . . . . . . . Assigning a Trigger Name . . . . . . Specifying the Trigger Event . . . . . Dening the Triggered Actions . . . . A Complete CREATE TRIGGER Statement
Using Triggered Actions . . . . . . . . . . . . . . . . . 13-7 Using BEFORE and AFTER Triggered Actions . . . . . . . . 13-7 Using FOR EACH ROW Triggered Actions . . . . . . . . . 13-9 Using the REFERENCING Clause . . . . . . . . . . . 13-9 Using the WHEN Condition . . . . . . . . . . . . . 13-10 Using Stored Procedures as Triggered Actions . . . . . . . . 13-11 Passing Data to a Stored Procedure . . . . . . . . . . 13-11 Using the Stored Procedure Language . . . . . . . . . 13-12 Updating Nontriggering Columns with Data from a Stored Procedure 13-12 Tracing Triggered Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13 . 13-15 . 13-15 . 13-17 . 13-18
Generating Error Messages . . . . . . Applying a Fixed Error Message . . . Generating a Variable Error Message . Summary . . . . . . . . . . . .
13-2
n SQL trigger is a mechanism that resides in the database. It is available to any user who has permission to use it. It species that when a particular actionan insert, a delete, or an updateoccurs on a particular table, the database server should automatically perform one or more additional actions. The additional actions can be INSERT, DELETE, UPDATE, or EXECUTE PROCEDURE statements. This chapter describes the purpose of each component of the CREATE TRIGGER statement, illustrates some uses for triggers, and describes the advantages of using a stored procedure as a triggered action.
When to Use Triggers

Because a trigger resides in the database and anyone who has the required privilege can use it, a trigger enables you to write a set of SQL statements that multiple applications can use. It enables you to prevent redundant code when multiple programs need to perform the same database operation. You can use triggers to perform the following actions as well as others that are not found in this list:
s
Create an audit trail of activity in the database. For example, you can track updates to the orders table by updating corroborating inforation to an audit table. Implement a business rule. For example, you can determine when an order exceeds a customers credit limit and display a message to that effect.
13-3
How to Create a Trigger
Derive additional data that is not available within a table or within the database. For example, when an update occurs to the quantity column of the items table, you can calculate the corresponding adjustment to the total_price column. Enforce referential integrity. When you delete a customer, for example, you can use a trigger to delete corresponding rows (that is, rows having the same customer number) in the orders table.
How to Create a Trigger

You use the CREATE TRIGGER statement to create a trigger. The CREATE TRIGGER statement is a data denition statement that associates SQL statements with a precipitating action on a table. When the precipitating action occurs, the associated SQL statements, which are stored in the database, are triggered. Figure 13-1 illustrates the relationship of the precipitating action, or trigger event, to the triggered action.
UPDATE
Figure 13-1 A trigger consists of a trigger event and a triggered action
item_num 2 3 4 5
quantity 3 1 4 1
total_price 15.00 236.00 100.00 280.00
EXECUTE PROCEDURE upd_items
trigger event
The CREATE TRIGGER statement consists of clauses that perform the following actions:
s s
Assign a trigger name. Specify the trigger event that is, the table and the type of action that initiate the trigger. Dene the SQL actions that are triggered.
13-4
Assigning a Trigger Name
An optional clause, called the REFERENCING clause is discussed in Using FOR EACH ROW Triggered Actions on page 13-9. You can create a trigger using the DB-Access utility, NewEra, INFORMIX-4GL, or one of the SQL APIs, INFORMIX-ESQL/C or INFORMIX-ESQL/COBOL. This section describes the CREATE TRIGGER statement as you would enter it using the interactive Query-language option in DB-Access. In an SQL API, you simply precede the statement with the symbol or keywords that identify it as an embedded statement. In NewEra and INFORMIX-4GL, you must end the trigger denition with the END TRIGGER keywords.
Assigning a Trigger Name

The trigger name identies the trigger. It follows the words CREATE TRIGGER in the statement. It can be up to 18 characters inclusive, in length, beginning with a letter and consisting of letters, the digits 0-9, and the underscore. In the following example, the portion of the CREATE TRIGGER statement that is shown assigns the name upqty to the trigger:
CREATE TRIGGER upqty -- assign trigger name
Specifying the Trigger Event

The trigger event is the type of statement that activates the trigger. When a statement of this type is performed on the table, the database server executes the SQL statements that make up the triggered action. The trigger event can be an INSERT, DELETE, or UPDATE statement. When you dene an UPDATE trigger event, you can name one or more columns in the table to activate the trigger. If you do not name any columns, then an update of any column in the table activates the trigger. You can create only one INSERT and one DELETE trigger per table, but you can create multiple UPDATE triggers as long as the triggering columns are mutually exclusive. In the following excerpt of a CREATE TRIGGER statement, the trigger event is dened as an update of the quantity column in the items table:
CREATE TRIGGER upqty UPDATE OF quantity ON items-- an UPDATE trigger event
13-5
Dening the Triggered Actions
Notice that this portion of the statement identies the table on which you create the trigger. If the trigger event is an insert or delete, only the type of statement and the table name are required, as shown in the following example:
CREATE TRIGGER ins_qty INSERT ON items -- an INSERT trigger event
Dening the Triggered Actions

The triggered actions are the SQL statements that are performed when the trigger event occurs. The triggered actions can consist of INSERT, DELETE, UPDATE, and EXECUTE PROCEDURE statements. In addition to specifying what actions are to be performed, however, you must also specify when they are to be performed in relation to the triggering statement. You have the following choices:
s s s
Before the triggering statement executes After the triggering statement executes For each row that is affected by the triggering statement
A single trigger can dene actions for each of these times. You dene a triggered action by specifying when it occurs and then providing the SQL statement or statements to execute. You specify when the action is to occur with the keywords BEFORE, AFTER, or FOR EACH ROW. The triggered actions follow, enclosed in parentheses. The following triggered action denition species that the stored procedure upd_items_p1 is to be executed before the triggering statement:
BEFORE(EXECUTE PROCEDURE upd_items_p1)-- a BEFORE action
13-6
A Complete CREATE TRIGGER Statement
A Complete CREATE TRIGGER Statement

If you combine the trigger name clause, the trigger event clause, and the triggered action clause, you have a complete CREATE TRIGGER statement. The following CREATE TRIGGER statement is the result of combining the components of the statement from the preceding examples. This trigger executes the stored procedure upd_items_p1 whenever the quantity column of the items table is updated.
CREATE TRIGGER upqty UPDATE OF quantity ON items BEFORE(EXECUTE PROCEDURE upd_items_p1)
Note that if a database object in the trigger denition, such as the stored procedure upd_items_p1 in this example, does not exist when the database server processes the CREATE TRIGGER statement, it returns an error.
Using Triggered Actions

To use triggers effectively, you need to understand the relationship between the triggering statement and the resulting triggered actions. You dene this relationship when you specify the time that the triggered action occurs that is, BEFORE, AFTER, or FOR EACH ROW.
Using BEFORE and AFTER Triggered Actions

Triggered actions that occur before or after the trigger event execute only once. A BEFORE triggered action executes before the triggering statement that is, before the occurrence of the trigger event. An AFTER triggered action executes after the action of the triggering statement is complete. BEFORE and AFTER triggered actions execute even if the triggering statement does not process any rows.
13-7
Using BEFORE and AFTER Triggered Actions
Among other uses, you can use BEFORE and AFTER triggered actions to determine the effect of the triggering statement. For example, before updating the quantity column in the items table, you could call the stored procedure upd_items_p1, shown in the following example, to calculate the total quantity on order for all items in the table. Notice that the procedure stores the total in a global variable called old_qty.
CREATE PROCEDURE upd_items_p1() DEFINE GLOBAL old_qty INT DEFAULT 0; LET old_qty = (SELECT SUM(quantity) FROM items); END PROCEDURE;
After the triggering update completes, you can calculate the total again to see how much it has changed. The following stored procedure, upd_items_p2, calculates the total of quantity again and stores the result in the local variable new_qty. Then it compares new_qty to the global variable old_qty to see if the total quantity for all orders has increased by more than 50 percent. If so, the procedure uses the RAISE EXCEPTION statement to simulate an SQL error.
CREATE PROCEDURE upd_items_p2() DEFINE GLOBAL old_qty INT DEFAULT 0; DEFINE new_qty INT; LET new_qty = (SELECT SUM(quantity) FROM items); IF new_qty > old_qty * 1.50 THEN RAISE EXCEPTION -746, 0, 'Not allowed - rule violation'; END IF END PROCEDURE;
The following trigger calls upd_items_p1 and upd_items_p2 to prevent an extraordinary update on the quantity column of the items table:
CREATE TRIGGER up_items UPDATE OF quantity ON items BEFORE(EXECUTE PROCEDURE upd_items_p1()) AFTER(EXECUTE PROCEDURE upd_items_p2());
If an update raises the total quantity on order for all items by more than 50 percent, the RAISE EXCEPTION statement in upd_items_p2 terminates the trigger with an error. When a trigger fails in INFORMIX-OnLine Dynamic Server and the database has logging, the database server rolls back the changes made by both the triggering statement and the triggered actions. See CREATE TRIGGER in Chapter 1 of the Informix Guide to SQL: Syntax for more information on what happens when a trigger fails.
13-8
Using FOR EACH ROW Triggered Actions

A FOR EACH ROW triggered action executes once for each row that the triggering statement effects. For example, if the triggering statement is has the following syntax:
UPDATE items SET quantity = quantity * 2 WHERE manu_code = 'KAR'
A FOR EACH ROW triggered action executes once for each row in the items table in which the manu_code column has a value of KAR. If the triggering statement does not process any rows, A FOR EACH ROW triggered action does not execute.
Using the REFERENCING Clause

When you create a FOR EACH ROW triggered action, you must usually indicate in the triggered action statements whether you are referring to the value of a column before or after the effect of the triggering statement. For example, imagine that you want to track updates to the quantity column of the items table. To do this, you create the following table to record the activity:
CREATE TABLE log_record (item_num SMALLINT, ord_num INTEGER, username CHARACTER(8), update_time DATETIME YEAR TO MINUTE, old_qty SMALLINT, new_qty SMALLINT);
To supply values for the old_qty and new_qty columns in this table, you must be able to refer to the old and new values of quantity in the items table; that is, the values before and after the effect of the triggering statement. The REFERENCING clause enables you to do this. The REFERENCING clause lets you create two prexes that you can combine with a column name, one to reference the old value of the column and one to reference its new value. These prexes are called correlation names. You can create one or both correlation names, depending on your requirements. You indicate which one you are creating with the keywords OLD and NEW. The following REFERENCING clause creates the correlation names pre_upd and post_upd to refer to the old and new values in a row:
REFERENCING OLD AS pre_upd NEW AS post_upd
13-9
The following triggered action creates a row in log_record when quantity is updated in a row of the items table. The INSERT statement refers to the old values of the item_num and order_num columns and to both the old and new values of the quantity column.
FOR EACH ROW(INSERT INTO log_record VALUES (pre_upd.item_num, pre_upd.order_num, USER, CURRENT, pre_upd.quantity, post_upd.quantity));
The correlation names dened in the REFERENCING clause apply to all rows affected by the triggering statement.
Important: If you refer to a column name in the triggering table without using a correlation name, the database server makes no special effort to search for the column in the denition of the triggering table. You must always use a correlation name with a column name in SQL statements within a FOR EACH ROW triggered action, unless the statement is valid independent of the triggered action. See CREATE TRIGGER in Chapter 1 of the Informix Guide to SQL: Syntax.
Using the WHEN Condition

As an option, you can precede a triggered action with a WHEN clause to make the action dependent on the outcome of a test. The WHEN clause consists of the keyword WHEN followed by the condition statement, given in parentheses. In the CREATE TRIGGER statement, the WHEN clause follows the keywords BEFORE, AFTER, or FOR EACH ROW and precedes the triggered action list. When a WHEN condition is present, if it evaluates to true, the triggered actions execute in the order in which they appear. If the WHEN condition evaluates to false or unknown, the actions in the triggered action list do not execute. If the trigger species FOR EACH ROW, the condition is evaluated for each row also. In the following trigger example, the triggered action executes only if the condition in the WHEN clause is true that is, if the post-update unit price is greater than two times the pre-update unit price:
CREATE TRIGGER up_price UPDATE OF unit_price ON stock REFERENCING OLD AS pre NEW AS post FOR EACH ROW WHEN(post.unit_price > pre_unit_price * 2) (INSERT INTO warn_tab VALUES(pre.stock_num, pre.order_num, pre.unit_price, post.unit_price, CURRENT))
13-10
Using Stored Procedures as Triggered Actions
See CREATE TRIGGER in Chapter 1 of the Informix Guide to SQL: Syntax for more information on the WHEN condition.
Using Stored Procedures as Triggered Actions

Probably the most powerful feature of triggers is the ability to call a stored procedure as a triggered action. The EXECUTE PROCEDURE statement, which calls a stored procedure, enables you to pass data from the triggering table to the stored procedure and also to update the triggering table with data returned by the stored procedure. SPL also lets you dene variables, assign data to them, make comparisons, and use procedural statements to accomplish complex tasks within a triggered action.
Passing Data to a Stored Procedure

You can pass data to a stored procedure in the argument list of the EXECUTE PROCEDURE statement. The EXECUTE PROCEDURE statement in the following trigger example passes values from the quantity and total_price columns of the items table to the stored procedure calc_totpr:
CREATE TRIGGER upd_totpr UPDATE OF quantity ON items REFERENCING OLD AS pre_upd NEW AS post_upd FOR EACH ROW(EXECUTE PROCEDURE calc_totpr(pre_upd.quantity, post_upd.quantity, pre_upd.total_price) INTO total_price)
Passing data to a stored procedure allows you to use it in the operations that the procedure performs.
13-11
Using Stored Procedures as Triggered Actions Using the Stored Procedure Language
The EXECUTE PROCEDURE statement in the preceding trigger calls the stored procedure that is shown in the following example. The procedure uses the SPL to calculate the change that needs to be made to the total_price column when quantity is updated in the items table. The procedure receives both the old and new values of quantity and the old value of total_price. It divides the old total price by the old quantity to derive the unit price. It then multiplies the unit price by the new quantity to obtain the new total price.
CREATE PROCEDURE calc_totpr(old_qty SMALLINT, new_qty SMALLINT, total MONEY(8)) RETURNING MONEY(8); DEFINE u_price LIKE items.total_price; DEFINE n_total LIKE items.total_price; LET u_price = total / old_qty; LET n_total = new_qty * u_price; RETURN n_total; END PROCEDURE;
In this example, SPL enables the trigger to derive data that is not directly available from the triggering table.
Updating Nontriggering Columns with Data from a Stored Procedure

Within a triggered action, the INTO clause of the EXECUTE PROCEDURE statement lets you update nontriggering columns in the triggering table. The EXECUTE PROCEDURE statement in the following example calls the calc_totpr stored procedure that contains an INTO clause, which references the column total_price:
FOR EACH ROW(EXECUTE PROCEDURE calc_totpr(pre_upd.quantity, post_upd.quantity, pre_upd.total_price) INTO total_price);
The value that is updated into total_price is returned by the RETURN statement at the conclusion of the stored procedure. The total_price column is updated for each row that the triggering statement affects.
13-12
Tracing Triggered Actions

If a triggered action does not behave as you expect, place it in a stored procedure and use the SPL TRACE statement to monitor its operation. Before starting the trace, you must direct the output to a le with the SET DEBUG FILE TO statement. The following example shows TRACE statements that have been added to the stored procedure items_pct. The SET DEBUG FILE TO statement directs the trace output to the le /usr/mydir/trig.trace. The TRACE ON statement begins tracing the statements and variables within the procedure.
CREATE PROCEDURE items_pct(mac CHAR(3)) DEFINE tp MONEY; DEFINE mc_tot MONEY; DEFINE pct DECIMAL; SET DEBUG FILE TO '/usr/mydir/trig.trace'; TRACE 'begin trace'; TRACE ON; LET tp = (SELECT SUM(total_price) FROM items); LET mc_tot = (SELECT SUM(total_price) FROM items WHERE manu_code = mac); LET pct = mc_tot / tp; IF pct > .10 THEN RAISE EXCEPTION -745; END IF TRACE OFF; END PROCEDURE; CREATE TRIGGER items_ins INSERT ON items REFERENCING NEW AS post_ins FOR EACH ROW(EXECUTE PROCEDURE items_pct (post_ins.manu_code));
13-13
Figure 13-2 shows sample trace output from the items_pct procedure as it appears in the le /usr/mydir/trig.trace. The output reveals the values of procedure variables, procedure arguments, return values, and error codes.
trace expression :begin trace trace on expression: (select (sum total_price) from items) evaluates to $18280.77 ; let tp = $18280.77 expression: (select (sum total_price) from items where (= manu_code, mac)) evaluates to $3008.00 ; let mc_tot = $3008.00 expression:(/ mc_tot, tp) evaluates to 0.16 let pct = 0.16 expression:(> pct, 0.1) evaluates to 1 expression:(- 745) evaluates to -745 raise exception :-745, 0, '' exception : looking for handler SQL error = -745 ISAM error = 0 error string = exception : no appropriate handler
Figure 13-2 Trace output from the items.pct stored procedure
= ''
See Chapter 12, Creating and Using Stored Procedures for more information on using the TRACE statement to diagnose logic errors in stored procedures.
13-14
Generating Error Messages
Generating Error Messages

When a trigger fails because of an SQL statement, the database server returns the SQL error number that applies to the specic cause of the failure. When the triggered action is a stored procedure, you can generate error messages for other error conditions by using one of two reserved error numbers. The rst one is error number -745, which has a generalized and xed error message. The second one is error number -746, which allows you to supply the message text, up to a maximum of 71 characters.
Applying a Fixed Error Message

You can apply error number -745 to any trigger failure that is not an SQL error. The following xed message is for this error:
-745 Trigger execution has failed.
You can apply this message with the RAISE EXCEPTION statement in SPL. The following example generates error -745 if new_qty is greater than old_qty multiplied by 1.50:
CREATE PROCEDURE upd_items_p2() DEFINE GLOBAL old_qty INT DEFAULT 0; DEFINE new_qty INT; LET new_qty = (SELECT SUM(quantity) FROM items); IF new_qty > old_qty * 1.50 THEN RAISE EXCEPTION -745; END IF END PROCEDURE
13-15
Applying a Fixed Error Message
If you are using DB-Access, the text of the message for error -745 displays on the bottom of the screen, as seen in Figure 13-3.
Figure 13-3 Error message -745 with xed message
Press CTRL-W for Help SQL: New Run Modify Use-editor Output Choose Save Modify the current SQL statements using the SQL editor. Info Drop Exit
---------------------- stores7@myserver --------- Press CTRL-W for Help ---INSERT INTO items VALUES( 2, 1001, 2, ' HRO ' , 1, 126.00);
745: Trigger execution has failed.
If you trigger the erring procedure through an SQL statement in your SQL API, the database server sets the SQL error status variable to -745 and returns it to your program. To display the text of the message, follow the procedure that your Informix application development tool provides for retrieving the text of an SQL error message.
13-16
Generating a Variable Error Message
Generating a Variable Error Message

Error number -746 allows you to provide the text of the error message. As with the preceding example, the following one also generates an error if new_qty is greater than old_qty multiplied by 1.50. However, in this case the error number is -746 and the message text Too many items for Mfr. is supplied as the third argument in the RAISE EXCEPTION statement. See the RAISE EXCEPTION statement in Chapter 12, Creating and Using Stored Procedures, for more information on the syntax and use of this statement.
CREATE PROCEDURE upd_items_p2() DEFINE GLOBAL old_qty INT DEFAULT 0; DEFINE new_qty INT; LET new_qty = (SELECT SUM(quantity) FROM items); IF new_qty > old_qty * 1.50 THEN RAISE EXCEPTION -746, 0, 'Too many items for Mfr.'; END IF END PROCEDURE;
If you use DB-Access to submit the triggering statement, and if new_qty is greater than old_qty, the result of this stored procedure is as shown in Figure 13-4.
Figure 13-4 Error number -746 with user-specied message text
Press CTRL-W for Help SQL: New Run Modify Use-editor Output Choose Save Modify the current SQL statements using the SQL editor.
Info
Drop
Exit
---------------------- store7@myserver --------- Press CTRL-W for Help ----INSERT INTO items VALUES( 2, 1001, 2, ' HRO ' , 1, 126.00);
746: Too many items for Mfr.
13-17
If you invoke the trigger through an SQL statement in an SQL API, the database server sets sqlcode to -746 and returns the message text in the sqlerrm eld of the SQL Communications Area (SQLCA). See the manual for your SQL API for in-depth information about using the SQLCA.
Summary
In introducing triggers, this chapter explains the following topics:
s s
The purpose of each component of the CREATE TRIGGER statement How to create BEFORE and AFTER triggered actions and how to use them to determine the impact of the triggering statement How to create a FOR EACH ROW triggered action and how to use the REFERENCING clause to refer to the values of columns both before and after the action of the triggering statement The advantages of using stored procedures as triggered actions How to trace triggered actions if they are behaving unexpectedly How to generate two types of error messages within a triggered action
s s s
Index
Index
A
Access control. See Privilege. Access modes discussed 7-16 Accessing data in a fragmented table 9-41 Accessing tables 12-18 Active set definition of 2-29 of a cursor 5-25 ADD ROWID clause, of ALTER TABLE 9-42 Aggregate function and GROUP BY clause 3-5 description of 2-53 in ESQL 5-15 in SPL expressions 14-24 in subquery 3-35 null value signalled 5-14 restrictions in modifiable view 11-25 Alias for table name 2-80 to assign column names in temporary table 3-12 with self-join 3-11 ALL keyword beginning a subquery 3-32 ALTER FRAGMENT statement example 9-38 INIT clause 9-42 MODIFY clause 9-38 ALTER INDEX statement locks table 7-8 Alter privilege 11-10
ALTER TABLE statement ADD ROWIDS clause 9-42 changing column data type 9-22 DROP ROWIDS clause 9-42 privilege for 11-10 American National Standards Institute. See ANSI. AND logical operator 2-37 ANSI 1-17 ANSI-compliant database buffered logging restricted in 9-26 description of 1-18 FOR UPDATE not required in 616 signalled in SQLAWARN 5-13 table privileges 11-8 ANY keyword beginning a subquery 3-34 Application common features 1-21 description of 1-19 design of order-entry 4-25 handling errors 5-18 report generator 1-20 screen forms 1-20 Archives with INFORMIX-SE 12-21 Archiving description of 1-11, 4-28 INFORMIX-OnLine Dynamic Server methods 4-29 transaction log 4-29 Arithmetic operator, in expression 2-47 Ascending order in SELECT 2-15
Asterisk wild card character in SELECT 2-12 Attribute identifying 8-17 important qualities of 8-17 nondecomposable 8-17 Automatic type conversion. See Data type conversion. AVG function as aggregate function 2-53
B
Bachman, C.R. 8-19 Backup. See Archive. BEGIN WORK statement specifies start of a transaction 4-27 BETWEEN keyword, used to test for equality in WHERE clause 2-29 BETWEEN operator 2-33 Boolean expression and logical operator 2-37 Buffered logging 9-26 Building your data model 8-3 to 8-38 BYTE data type description of 9-21 restrictions with GROUP BY 3-6 with LIKE or MATCHES 2-38 with relational expression 2-30 BYTE value, displaying 2-11
C
CALL statement assigning values with 14-24 executing a procedure 14-11 Candidate key defined 8-27 Cardinality 8-11 Cardinality in relationship 8-15 Cartesian product basis of any join 2-71 description of 2-69
Cascading deletes defined 4-23 locking associated with 4-23 logging 4-23 restriction 4-24 Chaining synonyms 12-20 Changing the number of fragments 9-39 CHAR data type description of 9-17 in relational expressions 2-30 subscripting 2-45 substrings of 2-27 truncation signalled 5-14 CHARACTER VARYING data type description of 9-18 Check constraint definition of 4-21 CLOSE DATABASE statement effect on database locks 7-7 COBOL 5-7 Codd, E. F. 1-12, 8-37 Collation order and NLS 2-25 Column defined 2-5 defining 8-24 description of 1-13 in relational model 1-13, 8-24 label on 3-46 Column number 2-24 Column-level privilege 11-11 Columns of a fragmented table, modifying 9-37 Command script, creating database 9-30 Commit, two-phase 12-22 COMMIT WORK statement closes cursors 7-22 releases locks 7-10, 7-22 sets SQLCODE 6- 5 Committed Read isolation level (Informix) 7-13 Comparison condition description of 2-29 Complex relationship 8-32 Composite key 8-27 Compound query 3-42 Computer network 12-4
Concurrency access modes 7-16 ANSI Read Committed isolation 7-13 ANSI Read Uncommitted isolation 7-12 ANSI Repeatable Read isolation 7-15 ANSI Serializable isolation 7-15 database lock 7-7 deadlock 7-18 description of 4-30, 7-3 effect on performance 7-3 Informix Cursor Stability isolation 7-13 Informix Dirty Read isolation 7-12 Informix Read Committed isolation 7-13 Informix Repeatable Read isolation 7-15 isolation level 7-11 kinds of locks 7-6 lock duration 7-9 lock scope 7-7 SERIAL values 9-9 table lock 7-8 Configuring a database server 12-17 Connect privilege 11-6 CONNECT statement opening a database 12-17 Connecting to data 12-14 Connectivity in relationship 8-10, 8-13, 8-20 Constraint cardinality 8-11 defining domains 9-4 CONTINUE statement exiting a loop 14-26 Conventions example code Intro-7 typographical Intro-5 Coordinated deletes 6- 6 Correlated subquery definition of 3-31 restriction with cascading deletes 4-24
INFORMIX
COUNT function and GROUP BY 3-6 as aggregate function 2-53 count rows to delete 4-5 use in a subquery 4-6 with DISTINCT 2-54 CREATE DATABASE statement in command script 9-30 sets shared lock 7-7 SQLAWARN after 5-13 using with INFORMIX-SE 9-27 OnLine 9-24 CREATE INDEX statement locks table 7-8 CREATE PROCEDURE FROM statement in embedded languages 14-6 CREATE PROCEDURE statement inside a CREATE PROCEDURE FROM 14-6 using 14-6 CREATE TABLE statement description of 9-28 in command script 9-30 sets initial SERIAL value 9-9 WITH ROWIDS clause 9-42 CREATE VIEW statement restrictions on 11-23 using 11-22 WITH CHECK OPTION keywords 11-27 CURRENT function comparing column values 2-56 Cursor active set of 5-25 closing 7-22 declaring 5-21 for insert 6- 9 for update 6- 15, 7-10 hold 7-22 opening 5-22, 5-25 retrieving values with FETCH 5-23 scroll 5-24 sequential 5-24, 5-26 with prepared statements 5-34 WITH HOLD 7-22
Cursor Stability isolation level (Informix) 7-13 Cyclic query 4-24
D
Daemon 12-15 Data connecting to 12-14 how to access in fragmented tables 9-41 integrity 12-22 Data definition statements 5-36 Data integrity 4-25 to 4-28, 12-22 Data model attribute 8-17 building 8-3 to 8-38 defining relationships 8-9 description of 1-4, 8-3 entity-relationship 8-5 many-to-many relationship 8-13 one-to-many relationship 8-13 one-to-one relationship 8-13 See also Relational model. telephone-directory example 8-7 Data protection with OnLine 12-21 Data replication 12-21 Data type automatic conversions 5-16 BYTE 9-21 CHAR 9-17 character data 9-17 CHARACTER VARYING 9-18 choosing 9-22 chronological 9-13 conversion 4-9 DATE 9-14 DATETIME 9-14 DECIMAL 9-11, 9-12 fixed-point 9-12 floating-point 9-10 in SPL variables 14-21 INTEGER 9-8 INTERVAL 9-15 MONEY 9-12 NCHAR 9-17 numeric 9-8
NVARCHAR 9-18 REAL 9-10 SERIAL 9-9 SMALLFLOAT 9-10 TEXT 9-20 VARCHAR 9-18 Database ANSI-compliant 1-18 application 1-19 archiving 1-11 concurrent use 1-9 defined 1-3, 1-12 management of 1-10 mission-critical 1-11 naming unique to engine 9-25 NLS 1-18 populating new tables 9-31 relational, defined 1-12 server 1-9, 1-19 server, definition of 1-19 stores7 Intro-9 table names 12-18 Database Administrator (DBA) 11-7 Database lock 7-7 Database management system 12-4 Database server configuration 12-17 definition of 1-19 local 12-6 remote 12-9 DATABASE statement exclusive mode 7-7 locking 7-7 SQLAWARN after 5-13 Database-level privilege description of 4-16 See also Privilege. DATE data type description of 9-14 functions in 2-56 in ORDER BY sequence 2-15 DATE function as time function 2-56 use in expression 2-60 DATETIME data type description of 9-14 displaying format 2-60, 9-16
Index
functions on 2-56 in ORDER BY sequence 2-15 relational expressions 2-30 precision and size 9-15 DAY function as time function 2-57 use as time function 2-56 DB-Access creating database with 5-36, 9-31 UNLOAD statement 9-32 DBANSIWARN environment variable 5-11 DBA-privileged procedure 14-16 DBDATE environment variable 4-9, 9-14 dbload utility loading data into a table 9-32 DBMONEY environment variable 9-13 DBMS. See Database management system. DBPATH environment variable 12-16 dbschema utility use of 9-30 DBSERVERNAME function use in SELECT 2-62, 2-65, 3-20 dbspace selecting with CREATE DATABASE 9-25 skipping if unavailable 5-11 Deadlock detection 7-18 DECIMAL data type fixed-point 9-12 floating-point 9-11 signalled in SQLAWARN 5-13 DECLARE statement description of 5-21 FOR INSERT clause 6- 9 FOR UPDATE 6- 15 SCROLL keyword 5-24 WITH HOLD clause 7-23 Default value description of 4-20 DEFINE statement in stored procedures 14-20
Delete privilege 11-9, 11-29 DELETE statement all rows of table 4-4 and end of data 6- 14 applied to view 11-25 coordinated deletes 6- 6 count of rows 6- 4 description of 4-4 embedded 5-7, 6- 3 to 6- 8 number of rows 5-13 preparing 5-32 privilege for 11-6, 11-9 transactions with 6- 5 using subquery 4-6 WHERE clause restricted 4-7 with cursor 6- 7 Demonstration database copying Intro-10 installation script Intro-9 overview Intro-9 Derived data produced by view 11-21 Descending order in SELECT 2-15 DESCRIBE statement describing statement type 5-35 Device optical 12-6 storage 12-6 Dirty Read isolation level (Informix) 7-12 Display label in ORDER BY clause 2-52 with SELECT 2-50 DISTINCT keyword relation to GROUP BY 3-4 restrictions in modifiable view 11-25 use in SELECT 2-20 with COUNT function 2-54 Distributed deadlock 7-19 Distributed processing 12-10 Distribution scheme changing the number of fragments 9-39 DOCUMENT keyword, use in stored procedures 14-7 Documentation notes Intro-8 Dominant table 3-21
DOS operating system 12-5 DROP INDEX statement locks table 7-8 DROP ROWIDS clause, of ALTER TABLE 9-42 Dropping a fragment 9-40 Duplicate values finding 3-15 Dynamic SQL cursor use with 5-34 description of 5-5, 5-30 freeing prepared statements 5-36
E
Embedded SQL defined 5-4 languages available 5-4 End of data signal in SQLCODE 5-12, 5-18 signal only for SELECT 6- 14 when opening cursor 5-22 Entity attributes associated with 8-17 business rules 8-5 criteria for choosing 8-8 defined 8-5 important qualities of 8-6 in telephone-directory example 8-9 integrity 4-19 naming 8-5 represented by a table 8-26 Entity occurrence, defined 8-19 Entity-relationship diagram connectivity 8-20 discussed 8-19 meaning of symbols 8-20 reading 8-21 Environment variable DBPATH 12-16 INFORMIXDIR 12-16 INFORMIXSERVER 12-16 PATH 12-16 TERMCAP 12-16 Equals (=) relational operator 2-31, 2-71 Equi-join 2-71
INFORMIX
Error checking exception handling 14-31 in stored procedures 14-31 simulating errors 14-34 Error messages for trigger failure 15-15 generating in a trigger 15-15 retrieving trigger text in a program 15-16, 15-18 Errors after DELETE 6- 4 at compile time 14-7 codes for 5-13 dealing with 5-18 detected on opening cursor 5-22 during updates 4-25 in stored procedure syntax 14-8 inserting with a cursor 6- 11 ISAM error code 5-13 ESCAPE keyword use with WHERE keyword 2-45 ESQL cursor use 5-21 to 5-29 DELETE statement in 6- 3 delimiting host variables 5-7 dynamic embedding 5-5, 5-30 error handling 5-18 fetching rows from cursor 5-23 host variable 5-6, 5-8 indicator variable 5-17 INSERT in 6- 9 overview 5-3 to 5-40, 6- 3 to 6- 18 preprocessor 5-4 scroll cursor 5-24 selecting single rows 5-14 SQL Communications Area 5-9 SQLCODE 5-12 SQLERRD fields 5-13 static embedding 5-5 UPDATE in 6- 15 Exclusive lock 7-6 EXECUTE IMMEDIATE statement description of 5-36 EXECUTE PROCEDURE statement assigning values with 14-24 using 14-11 EXECUTE statement description of 5-33
Existence dependency 8-10 EXISTS keyword in a WHERE clause 3-32 use in condition subquery 11-28 EXIT statement exiting a loop 14-26 Expression date-oriented 2-56 description of 2-47 display label for 2-50 EXTEND function with DATE, DATETIME and INTERVAL 2-56, 2-60
F
FETCH statement ABSOLUTE keyword 5-25 description of 5-23 sequential 5-24 with sequential cursor 5-26 File compared to database 1-4 permissions in UNIX 11-4 First normal form 8-34 Fixed point 9-12 FLOAT data type description of 9-10 Floating point 9-10 FLUSH statement count of rows inserted 6- 11 writing rows to buffer 6- 10 FOR statement looping in a stored procedure 14-26 FOR UPDATE keywords conflicts with ORDER BY 6- 8 not needed in ANSI-compliant database 6- 16 specific columns 6- 16 FOREACH statement looping in a stored procedure 14-26 Foreign key 4-21 Fragment altering 9-38 dropping 9-40
Fragmentation strategy modifying 9-38 Fragmented table accessing data 9-41 created from multiple nonfragmented table 9-36 creating 9-36 creating from one nonfragmented table 9-37 how to create 9-34 modifying 9-37 use of rowid 9-41 using primary keys 3-15, 9-41 FREE statement freeing prepared statements 5-36 FROM keyword alias names 2-80 Function aggregate 2-53 date-oriented 2-56 in SELECT statements 2-53 within a stored procedure 14-27 Functional dependency 8-36
G
Global transaction 12-23 GRANT statement automated 11-13 database-level privileges 11-6 in 4GL 11-14 in embedded SQL 5-37 to 5-39 table-level privileges 11-8 GROUP BY keywords column number with 3-7 description of 3-4 restrictions in modifiable view 11-25
H
HAVING keyword description of 3-8 Header, of a procedure 14-28 Hold cursor definition of 7-22 Host machine 12-9
Index
Host variable delimiter for 5-7 description of 5-6 dynamic allocation of 5-35 fetching data into 5-23 in DELETE statement 6- 4 in INSERT 6- 9 in UPDATE 6- 15 in WHERE clause 5-15 INTO keyword sets 5-15 null indicator 5-17 restrictions in prepared statement 5-31 truncation signalled 5-14 with EXECUTE 5-33
I
IF statement branching 14-25 IN keyword used to test for equality in WHERE clause 2-29 IN relational operator 3-32 Index locks table 7-8 Index privilege 11-10 Indicator variable definition of 5-17 INFORMIX-4GL 12-6 detecting null value 5-17 example of dynamic SQL 11-14 indicator variable not used 5-17 program variable 5-6 STATUS variable 5-12 terminates on errors 5-39, 6- 14 using SQLCODE with 5-12 WHENEVER ERROR statement 5-39 INFORMIXDIR environment variable 12-16 INFORMIX-OnLine Dynamic Server allows views on external tables 11-24 archiving 4-29 characteristics of 1-11
signalled in SQLAWARN 5-13 when tables are locked 7-8 INFORMIX-OnLine/Optical 12-6 INFORMIX-SE characteristics of 1-10 creating database 9-27 INFORMIXSERVER environment variable 12-16 INFORMIX-SQL creating database with 5-36, 9-31 UNLOAD statement 9-31 Insert cursor definition of 6- 9 use of 6- 12 Insert privilege 11-9, 11-29 INSERT statement and end of data 6- 14 constant data with 6- 12 count of rows inserted 6- 11 duplicate values in 4-8 embedded 6- 9 to 6- 14 inserting multiple rows 4-10 rows 4-7 single rows 4-7 null values in 4-8 number of rows 5-13 privilege for 11-6, 11-9 SELECT statement in 4-10 VALUES clause 4-7 with a view 11-26 Inserting rows of constant data 612 INTEGER data type description of 9-8 Integrity. See Data integrity. Interrupted modifications 4-25 INTERVAL data type description of 9-15 display format 9-16 in relational expressions 2-30 precision and size 9-16 INTO keyword choice of location 5-24 in FETCH statement 5-24 mismatch signalled in SQLAWARN 5-14 restrictions in INSERT 4-11
restrictions in prepared statement 5-31 retrieving multiple rows 5-21 retrieving single rows 5-15 INTO TEMP keywords description of 2-83 restrictions in view 11-23 ISAM error code 5-13 Isolation level ANSI Read Committed 7-13 ANSI Read Uncommitted 7-12 ANSI Repeatable Read 7-15 ANSI Serializable 7-15 description of 7-11 Informix Committed Read 7-13 Informix Cursor Stability 7-13 Informix Dirty Read 7-12 Informix Repeatable Read 7-15 setting 7-11
J
Join associative 2-76 creating 2-71 definition of 2-9 dominant table 3-21 equi-join 2-71 multiple-table join 2-78 natural 2-75 nested outer 3-27 nested simple 3-24 outer 3-21 restrictions in modifiable view 11-25 self-join 3-11 subservient table 3-21 Join column. See Foreign key.
K
Key lock 7-9 Key, composite 8-27 Key, primary 8-26
INFORMIX
L
Label 2-50, 3-46 LENGTH function on TEXT 2-63 on VARCHAR 2-63 use in expression 2-62 LET statement assigning values 14-24 executing a procedure 14-11 LIKE keyword, used to test for equality in WHERE clause 2-29 LIKE relational operator 2-38 Local loopback 12-10 Local server 12-6 LOCK TABLE statement locking a table explicitly 7-8 Locking and concurrency 4-30 and integrity 7-3 deadlock 7-18 description of 7-6 granularity 7-7 lock duration 7-9 lock mode 7-17 not-wait 7-17 wait 7-17 locks released at end of transaction 7-22 scope 7-7 scope of lock 7-7 setting lock mode 7-17 types of locks database lock 7-7 exclusive lock 7-6 key lock 7-9 page lock 7-9 promotable lock 7-6, 7-10 row lock 7-9 shared lock 7-6 table lock 7-8 with DELETE 6- 4 update cursor 7-10
Logging buffered 9-26 choosing for OnLine database server 9-26 choosing for SE database server 9-27 unbuffered 9-26 Logical log definition of 4-28 Logical operator AND 2-37 NOT 2-37 OR 2-37 Loop creating and exiting in SPL 14-26 exiting using RAISE exception 14-35 Loopback, local 12-10
MODIFY clause of ALTER FRAGMENT 9-38 Modifying a fragmentation strategy 9-38 Modifying fragmented tables 9-37 MONEY data type 9-13 description of 9-12 display format 9-13 in INSERT 4-9 MONTH function as time function 2-56 Multiple-table join 2-78
N
Naming conventions tables 12-18 Natural join 2-75 NCHAR data type description of 9-17 Nested ordering, in SELECT 2-16 Network computer 12-4 connection information 12-17 site 12-4 New features for Version 7.1 Intro-12 NLS activating 2-25 and collation order 2-25 and MATCHES keyword 2-43 and ORDER BY keywords 2-25, 2-43 specifying a language environment 2-25 NLS database description of 1-18 Nondecomposable attributes 8-17 Normal form 8-33 Normalization benefits 8-33 first normal form 8-34 of data model 8-33 rules 8-33 rules, summary 8-37 second normal form 8-36 third normal form 8-36 NOT logical operator 2-37
M
Machine notes Intro-8 Mandatory, entity in relationship 8-10 Many-to-many relationship 8-10, 8-13, 8-30 MATCHES keyword use with NLS 2-43 used to test for equality in WHERE clause 2-29 MATCHES relational operator in WHERE clause 2-38 MAX function as aggregate function 2-53 MDY function as time function 2-56 Memory shared 12-8 Message files error messages Intro-8 MIN function as aggregate function 2-53 MODE ANSI keywords ANSI-compliant database 1-18 ANSI-compliant logging 9-26 specifying transactions 4-27 Model. See Data model.
Index
NOT NULL keywords use in CREATE TABLE 9-28 NOT relational operator 2-33 NULL relational operator 2-37 Null value defined 9-22 detecting in ESQL 5-17 in INSERT statement 4-8 restrictions in primary key 8-26 testing for 2-37 with logical operator 2-37 Number of fragments, changing 9-39 NVARCHAR data type description of 9-18
multiple columns 2-15 relation to GROUP BY 3-6 restrictions in INSERT 4-11 restrictions in view 11-23 restrictions with FOR UPDATE 6- 8 select columns by number 2-24 sorting rows 2-14 Output from TRACE command 15-14 Owner-privileged procedure 14-16 Ownership 11-8
P
Page lock 7-9 Parameter to a stored procedure 14-28 Parts explosion 5-28 PATH environment variable 12-16 Performance buffered log 9-26 depends on concurrency 7-3 increasing with stored procedures 14-4 Pipes, unnamed 12-8 Populating tables 9-31 PREPARE statement description of 5-31 error return in SQLERRD 5-13 missing WHERE signalled 5-11 multiple SQL statements 5-32 preparing GRANT 11-14 Primary key definition of 8-26 restrictions with 8-26 Primary key constraint composite 8-27 definition of 4-21 Primary key, use in fragmented table 3-15, 9-41 Primary site 12-21 Privilege Alter 11-10 and views 11-28 to 11-31 automating grants of 11-13 column-level 11-11 Connect 11-6
O
ON EXCEPTION statement scope of control 14-32 trapping errors 14-31 user-generated errors 14-34 One-to-many relationship 8-10, 8-13 One-to-one relationship 8-10, 8-13 On-line files Intro-8 onload utility 4-30 onunload utility 4-30 OPEN statement activating a cursor 5-22 opening select or update cursors 5-22 Opening a cursor 5-22, 5-25 Operating system DOS 12-5 UNIX 12-5 Optical device 12-6 Optional, entity in relationship 8-10 OR logical operator 2-37 OR relational operator 2-34 ORDER BY keywords and NLS 2-25 ascending order 2-15 DESC keyword 2-15, 2-25 display label with 2-52
DBA 11-7 default for stored procedures 14-17 Delete 11-9, 11-29 displaying 4-18 encoded in system catalog 11-9 Execute 11-13, 14-17 granting 11-6 to 11-15 Index 11-10 Insert 11-9, 11-29 needed to create a view 11-28 to modify data 4-16 on a view 11-29 on stored procedures 14-16 overview 1-9 Resource 11-7 Select 11-9, 11-11, 11-28 Update 11-9, 11-11, 11-29 with DBA-privileged procedures 14-16 with owner-privileged procedures 14-16 Processing, distributed 12-10 Projection, described 2-7 Project, description of 1-14 Promotable lock 7-6, 7-10 PUBLIC keyword privilege granted to all users 11-7 PUT statement constant data with 6- 12 count of rows inserted 6- 11 sends returned data to buffer 610
Q
Query cyclic 4-24 self-referencing 4-24 stated in terms of data model 1-7
R
RAISE EXCEPTION statement exiting a loop 14-26 Read Committed isolation level (ANSI) 7-13
INFORMIX
Read Uncommitted isolation level (ANSI) 7-12 Recursion, in a stored procedure 14-27 Recursive relationship 8-12, 8-32 Redundant relationship 8-32 REFERENCING clause using referencing 15-9 Referential constraint definition of 4-21 Referential integrity 4-21 defining primary and foreign keys 8-28 Relational database, defined 1-12 Relational model attribute 8-17 description of 1-12, 8-3 to 8-38 entity 8-5 join 2-9 many-to-many relationship 8-13 normalizing data 8-33 one-to-many relationship 8-13 one-to-one relationship 8-13 projection 2-7 resolving relationships 8-30 rules for defining tables, rows, and columns 8-24 selection 2-6 Relational operation 2-5 Relational operator BETWEEN 2-33 equals 2-31 EXISTS 3-32 IN 3-32 in a WHERE clause 2-29 to ?? LIKE 2-38 NOT 2-33 NULL 2-37 OR 2-34 Relationship attribute 8-17 cardinality 8-11, 8-15 complex 8-32 connectivity 8-10, 8-13 defining in data model 8-9 entity 8-6 existence dependency 8-10 mandatory 8-10 many-to-many 8-10, 8-13
many-to-many, resolving 8-30 one-to-many 8-10, 8-13 one-to-one 8-10, 8-13 optional 8-10 recursive 8-32 redundant 8-32 using matrix to discover 8-11 Release notes Intro-8 Remote database server 12-9 Repeatable Read isolation level (Informix and ANSI) description of 7-15 Replication of data 12-21 Report generator 1-20 Resource manager 12-13 Resource privilege 11-7 Restricting access, using file system 11-4 RETURN statement exiting a loop 14-26 REVOKE statement granting privileges 11-6 to 11-15 in embedded SQL 5-37 to 5-39 with a view 11-30 ROLLBACK WORK statement cancels a transaction 4-27 closes cursors 7-22 releases locks 7-10, 7-22 sets SQLCODE 6- 5 ROLLFORWARD DATABASE statement applies log to restored database 4-29 Row defined 2-5 defining 8-24 deleting 4-4 description of 1-13 in relational model 1-13, 8-24 inserting 4-7 Row lock 7-9 Rowid creating in a fragmented table 9-42 description of 9-41 dropping in a fragmented table 9-42 in fragmented tables 9-41
locating internal row numbers 3-17 use in a join 3-15
S
Schema. See Data Model. Scroll cursor active set 5-26 definition of 5-24 SCROLL keyword use in DECLARE 5-24 Second normal form 8-36 Secondary site 12-21 Security constraining inserted values 11-21, 11-27 database-level privileges 11-5 making database inaccessible 11-5 restricting access to columns 11-21, 11-22 restricting access to rows 11-21, 11-22 restricting access to view 11-28 table-level privileges 11-11 using host file system 11-4 using operating system facilities 11-4 with stored procedures 11-3 Select description of 1-14 Select cursor opening 5-22 use of 5-22 Select list display label 2-50 expressions in 2-47 functions in 2-53 to 2-66 labels in 3-46 selecting all columns 2-12 selecting specific columns 2-18 specifying a substring in 2-27 Select privilege column level 11-11 definition of 11-9 with a view 11-28
Index
SELECT statement active set 2-29 aggregate functions in 2-53 alias names 2-80 assigning values with 14-24 compound query 3-42 cursor for 5-21 date-oriented functions in 2-56 description of advanced 3-4 to 3-54 description of simple 2-3 to 2-83 display label 2-50 DISTINCT keyword 2-20 embedded 5-15 to 5-17 for joined tables 2-69 to 2-83 for single tables 2-12 to 2-66 functions 2-53 to 2-66 GROUP BY clause 3-4 HAVING clause 3-8 in modifiable view 11-25 INTO TEMP clause 2-83 join 2-71 to 2-79 multiple-table 2-69 natural join 2-75 ORDER BY clause 2-14 outer join 3-21 to 3-30 privilege for 11-6, 11-9 rowid 3-15, 3-20 SELECT clause 2-12 to 2-28 selecting a substring 2-27 selecting expressions 2-47 selection list 2-12 self-join 3-11 single-table 2-12 singleton 2-29 subquery 3-31 to 3-41 UNION operator 3-42 using for join 2-9 for projection 2-7 for selection 2-6 Selection, described 2-6 Self-join assigning column names with INTO TEMP 3-12 description of 3-11 Self-referencing query 3-11, 4-24 Semantic integrity 4-20, 9-3
Sequential cursor definition of 5-24 SERIAL data type description of 9-9 generated number in SQLERRD 5-13 inserting a starting value 4-9 Serializable isolation level (ANSI) description of 7-15 Server. See Database server. SET clause 4-15 Set difference 3-52 Set intersection 3-50 SET ISOLATION statement controlling the effect of locks 4-31 discussed 7-11 similarities to SET TRANSACTION statement 7-11 SET keyword use in UPDATE 4-13 SET LOCK MODE statement controlling the effect of locks 4-31 description of 7-17 SET LOG statement buffered vs. unbuffered 9-26 SET TRANSACTION statement similarities to SET ISOLATION statement 7-11 Shared memory network connection 12-8 Singleton SELECT statement 2-29 Site network 12-4 primary 12-21 secondary 12-21 SITENAME function use in SELECT 2-62, 2-65, 3-20 SMALLFLOAT data type description of 9-10 SMALLINT data type description of 9-8 SOME keyword beginning a subquery 3-32 Sorting nested 2-15 with NLS activated 2-25 with ORDER BY 2-15
SPL flow control statements 14-25 program variable 5-6 relation to SQL 14-3 SQL ANSI standard 1-17 cursor 5-21 description of 1-16 error handling 5-18 history 1-17 Informix SQL and ANSI SQL 1-17 interactive use 1-20 standardization 1-17 SQL Communications Area (SQLCA) altered by end of transaction 6- 5 description of 5-9 inserting rows 6- 11 SQLAWARN array description of 5-13 syntax of naming 5-12 with PREPARE 5-32 SQLCODE field after opening cursor 5-22 description of 5-12 end of data on SELECT only 6- 14 end of data signalled 5-18 set by DELETE 6- 4 set by DESCRIBE 5-35 set by PUT, FLUSH 6- 11 SQLERRD array count of deleted rows 6- 4 count of inserted rows 6- 11 count of rows 6- 14 description of 5-13 syntax of naming 5-12 sqlexecd 12-15 sqlhosts. See $INFORMIXDIR/etc/sqlhosts. SQLSTATE in databases that are not ANSIcompliant 5-18 use with a cursor 5-22 START DATABASE statement adding a transaction log 9-27 Static SQL 5-5 STATUS variable (4GL) 5-12 Storage device 12-6
10
INFORMIX
Stored procedure altering 14-15 as triggered action 15-11 branching 14-25 comments in 14-7 creating from an embedded language 14-6 creating from DB-Access 14-6 DBA-privileged, use with triggers 14-16 debugging 14-13 default privileges 14-17 DEFINE statement 14-20 definition of 14-4 displaying contents 14-10 displaying documentation 14-11 executing 14-11 general programming 1-21 granting privileges on 11-13, 14-17, 14-18 header 14-28 in SELECT statements 2-67 introduction to 14-3 looping 14-26 name confusion with SQL functions 14-24 owner-privileged 14-16 privileges necessary at execution 14-17 program flow control 14-25 recursion 14-27 REFERENCES clause 14-21 returning values 14-28 revoking privileges on 14-19 security purposes 11-3 tracing triggered actions 15-13 use 14-4 variable 14-19 stores7 database copying Intro-10 creating Intro-10 overview Intro-9 Structured Query Language. See SQL. Subquery correlated 3-31, 4-24 in DELETE statement 4-6 in SELECT 3-31 to 3-41
in UPDATE-SET 4-14 in UPDATE-WHERE 4-13 Subscripting in a WHERE clause 2-45 SPL variables 14-21 Subservient table 3-21 Substring 2-27, 14-21 SUM function as aggregate function 2-53 Synonym chains 12-20 Synonyms for table names 12-19 syssyntable system catalog table 12-19 System catalog privileges in 4-18, 11-9 querying 4-18 syscolauth 11-9 sysprocbody 14-10 systabauth 4-18, 11-9 sysusers 11-9
T
Table candidate keys, defined 8-27 composite key, defined 8-27 creating 9-28 description of 1-12 in relational model 1-12, 8-24 lock 7-8 names 12-18 names, synonyms 12-19 ownership 11-8 primary key in 8-26 primary key, defined 8-26 represents an entity 8-26 Table-level privilege column-specific privileges 11-11 definition and use 11-8 Temporary table and active set of cursor 5-26 assigning column names 3-12 example 4-12 TERMCAP environment variable 12-16
TEXT data type description of 9-20 restrictions with GROUP BY 3-6 with LIKE or MATCHES 2-38 with relational expression 2-30 with LENGTH function 2-63 TEXT value, displaying 2-11 Third normal form 8-36 TODAY function use in constant expression 2-62, 4-9 TP/XA. See Transaction manager. TRACE command output from 15-14 TRACE statement debugging a stored procedure 14-13 Transaction cursors closed at end 7-22 description of 4-25 example with DELETE 6- 5 global 12-23 locks held to end of 7-10 locks released at end 7-10, 7-22 transaction log 4-26, 4-29 transaction log required 9-26 use signalled in SQLAWARN 5-13 Transaction logging buffered 9-26 contents of log 4-28 establishing with CREATE DATABASE 9-24 OnLine methods of 9-26 turning off for faster loading 9-33 turning off not possible 9-27 Transaction manager 12-13 Transitive dependency 8-36 Trigger creating 15-4 definition of 15-3 when to use 15-3 Trigger event definition of 15-5 example of 15-5 Trigger name assigning 15-5
Index
11
Triggered action BEFORE and AFTER 15-7 FOR EACH ROW 15-9 generating an error message 15-15 in relation to triggering statement 15-6 statements 15-3 tracing 15-13 using 15-7 using stored procedures 15-11 WHEN condition 15-10 Truncation, signalled in SQLAWARN 5-14 Two-phase commit 12-22 Typographical conventions Intro-5
number of rows 5-13 preparing 5-32 privilege for 11-6, 11-9 restrictions on subqueries 4-15 USER function use in expression 2-62, 2-63, 3-19 USING keyword use in EXECUTE 5-33 Utility program dbload 9-32 dbschema 9-30 onload 4-30 onunload 4-30
W
Warning if dbspace is skipped 5-11 Warnings, with stored procedures at compile time 14-9 WEEKDAY function as time function 2-56, 2-59 WHERE clause, subscripting 2-45 WHERE CURRENT OF keywords use in DELETE 6- 7 in UPDATE 6- 15 WHERE keyword Boolean expression in 2-37 comparison condition 2-29 to ?? date-oriented functions in 2-59 enforcing data constraints 11-28 host variables in 5-15 in DELETE 4-4 to 4-7 null data tests 2-37 range of values 2-33 relational operators 2-29 selecting rows 2-28 subqueries in 3-32 testing a subscript 2-45 use with NOT keyword 2-33 with OR keyword 2-34 wildcard comparisons 2-38 WHILE statement looping in a stored procedure 14-26 Wildcard character asterisk 2-12 Wildcard comparison in WHERE clause 2-38 to 2-45 WITH CHECK OPTION keywords of CREATE VIEW statement 11-27 WITH HOLD keywords declaring a hold cursor 7-23 WITH LISTING IN keywords warnings in a stored procedure 14-10 WITH ROWIDS clause, of CREATE TABLE 9-42
U
Unbuffered logging 9-26 UNION operator description of 3-42 display labels with 3-46 restrictions in view 11-23 UNIQUE keyword constraint in CREATE TABLE 9-28 restrictions in modifiable view 11-25 use in SELECT 2-20 UNIX operating system 12-5, 12-7 UNLOAD statement exporting data to a file 9-31 Unnamed pipes 12-8 Update cursor definition of 6- 15 Update privilege column level 11-11 definition of 11-9 with a view 11-29 UPDATE statement and end of data 6- 14 applied to view 11-25 description of 4-12 embedded 6- 15 to 6- 17 missing WHERE signalled 5-11 multiple assignment 4-15
V
VALUES clause use in INSERT 4-7 VARCHAR data type description of 9-18 value, displaying 2-11 with LENGTH function 2-63 Variable global, in SPL 14-20 in SPL 14-19 local, in SPL 14-20 with same name as a keyword 14-22 View creating a view 11-22 deleting rows in 11-25 description of 11-21 dropped when basis is dropped 11-24 effect of changing basis 11-24 inserting rows in 11-26 modifying 11-25 to 11-28 null inserted in unexposed columns 11-27 privilege when accessing 11-29 privileges 11-28 to 11-31 produces duplicate rows 11-23 updating duplicate rows 11-26 using CHECK OPTION 11-27 virtual column 11-25
12
INFORMIX
WORM drive 12-6 Write-once read-many-times device. See WORM drive.
Y
YEAR function as time function 2-56
Symbols
$INFORMIXDIR/etc/sqlhosts 1217 /etc/hosts 12-17 /etc/services 12-17 =, equals, relational operator 2-31, 2-71 ?, question mark as placeholder in PREPARE 5-31
Index
13
14
INFORMIX

Informix Guide To SQL-Tutorial

Uploaded by

Copyright:

Available Formats

Informix Guide To SQL-Tutorial

Uploaded by

Copyright:

Available Formats

Informix Guide to SQL

Version 7.1 December 1994 Part No. 000-7634

Published by INFORMIX Press

Informix Software, Inc. 4100 Bohannon Drive Menlo Park, CA 94025

Informix Guide to SQL: Tutorial

Informix Guide to SQL: Tutorial

Informix Welcomes Your Comments

Informix Welcomes Your Comments

Informix Guide to SQL: Tutorial

UNIX System V: A Practical Guide by M. Sobell (Benjamin/Cummings

New Features in Informix Version 7.1 Products That Use SQL . . . . . . . . . .

Section I Using Basic SQL

Composing Simple SELECT Statements

x Informix Guide to SQL: Tutorial

2-47 2-53 2-67 2-69 2-69 2-71 2-80 2-84

Composing Advanced SELECT Statements

Set Operations . . . . . . . . . . . . . . . Union . . . . . . . . . . . . . . . . Intersection . . . . . . . . . . . . . . Difference . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . .

Data Replication . . . . . . . . . INFORMIX-OnLine Dynamic Server Data Replication . . . . . Summary . . . . . . . . . . . .

Programming with SQL

Informix Guide to SQL: Tutorial

Modifying Data Through SQL Programs

Using UPDATE . . . . . Using an Update Cursor . Cleaning up a Table. . . Summary . . . . . . .

Programming for a Multiuser Environment

Locking and Performance . Concurrency Issues . . .

Informix Guide to SQL: Tutorial

Hold Cursors . Summary . .

Section II Designing and Managing Databases

Normalizing Your Data Model . Summary . . . . . . . .

Implementing Your Data Model

. . . . . . . . . 9-24 . . . . . . . . . 9-24 . . . . . . . . . 9-28 . . . . . . . . . 9-30 . . . . . . . . . 9-31 . . . . . . . . . . . . . . . . . . . . . . . 9-34 . 9-34 . 9-35 . 9-36

Fragmenting Tables and Indexes .

Granting and Limiting Access to Your Database

. . . . . . 11-16 . . . . . . 11-16 . . . . . . 11-17 . . . . . . 11-18 . . . . . . 11-20

Informix Guide to SQL: Tutorial

Understanding Informix Networking

Section III Using Advanced SQL

. . . . . . . 14-16 . . . . . . . 14-17 . . . . . . . 14-17 . . . . . . . 14-19

Informix Guide to SQL: Tutorial

Creating and Using Triggers

Informix Guide to SQL: Tutorial

New Features in Informix Version 7.1 Products That Use SQL . . . . . . . . . .

Informix Guide to SQL: Tutorial

Informix Products That Use SQL

Products Covered in This Manual

Products Covered in This Manual

Other Useful Documentation

Informix Guide to SQL: Tutorial

How to Use This Manual

How to Use This Manual

Informix Guide to SQL: Tutorial

Example Code Conventions

Example Code Conventions

Useful On-Line Files

Useful On-Line Files

ASCII and PostScript Error Message Files

Informix Guide to SQL: Tutorial

The Demonstration Database

The Demonstration Database

The database name should be unique.

Creating the Demonstration Database

Creating the Demonstration Database

Informix Guide to SQL: Tutorial

Creating the Demonstration Database

Compliance with Industry Standards

Compliance with Industry Standards

Effective checking of constraints Serializable transactions

New Features in Informix Version 7.1 Products That Use SQL

Informix Guide to SQL: Tutorial

New Features in Informix Version 7.1 Products That Use SQL

New Features in Informix Version 7.1 Products That Use SQL

WITH REOPTIMIZATION clause for the OPEN CURSOR statement

INTO clause for the EXECUTE statement