Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Introduction to the Teradata® RDBMS for UNIX® Version 2 Release 2.1 - NCR

NCR Introduction to the Teradata® RDBMS for UNIX® Version 2 Release 2.1 - NCR, 1998. - 315 p.
Download (direct link): inntroduktionteradata1998.pdf
Previous << 1 .. 31 32 33 34 35 36 < 37 > 38 39 40 41 42 43 .. 76 >> Next


5-19
Data Manipulation

Using Teradata SQL in Application Programs

Introduction

Embedded SQL and Client Programming Languages

Using Teradata SQL in Application Programs

So far, the discussion of Teradata SQL has concerned how to use it in interactive queries from a user terminal. In fact, SQL statements are more frequently used in application programs, particularly in an OLTP environment. This topic introduces the subject of embedded SQL and describes some of the additional statements you must include to use SQL in your applications.

The Teradata RDBMS supports embedded SQL programming for several different client platforms.

When you develop an application using one of these languages, you embed the SQL code within the client programming language. You use slightly different mechanisms for doing this depending on the language, but the beginning of a SQL code set usually begins with a prefix something like

EXEC SQL

and ends with some terminating symbol, depending on the language. Note: unlike interactive SQL, embedded SQL contains several nonexecutable, declarative statements.

After you have coded the application, you can test it. To do this, you must first process it through a program that translates the SQL into native code. It does this by commenting out all the SQL code and substituting executable statements using CLI calls. The program that performs this translation is called a precompiler, and the Teradata SQL precompiler is called Preprocessor2. In the final step, you compile the native code with its compiler and test it.

Language Platform
COBOL • IBM mainframe clients
• Some workstation clients
PL/I IBM mainframe clients
C • IBM mainframe clients
• UNIX clients

5-20

Introduction to the Teradata RDBMS for UNIX
Data Manipulation

Using Teradata SQL in Application Programs

Because SQL is a set-oriented language, traditional application development languages cannot deal with results tables without some kind of intermediary mechanism. That mechanism is the cursor.

A cursor is a pointer that the application program uses to move through a results table one row (record in programming language terminology) at a time. You declare a cursor for a SELECT statement and then open the named cursor. The act of opening the cursor causes the SQL statement to be executed. The rows are individually fetched and written into host variables using a FETCH ... INTO ... statement. The application can then use the host variables to do computations.

Because there are typically multiple records in the results table, the FETCH is normally embedded within a loop so the results can be processed until the last record has been processed. You can also use cursors with the UPDATE and DELETE statements.

Introduction to the Teradata RDBMS for UNIX

5-21
Data Manipulation

For More Information

For More Information

For more information on the topics presented in this chapter, see the following Teradata RDBMS manuals.

IF you want to learn more about . . . THEN see this manual . . .
Teradata SQL data manipulation statements Teradata RDBMS for UNIX SQL Reference
Embedded SQL Teradata RDBMS for UNIX SQL Reference Manual Teradata Application Programming With Embedded SQL for C, COBOL, and PL/I
Teradata SQL join capabilities Teradata RDBMS for UNIX Database Design and Administration

5-22

Introduction to the Teradata RDBMS for UNIX
Views

Chapter 6

Views

Introduction to the Teradata RDBMS for UNIX
Views

Introduction to the Teradata RDBMS for UNIX
Views

About This Chapter

Introduction

Why Use Views?

About This Chapter

This chapter discusses relational database views.

A view is a virtual table that appears to the user as a base table. You can think of a view as a dynamic window on the underlying database.

Views are constructed from one or more base tables (or views) but usually present only a subset of the columns in the base table or tables that comprise them.

Some view columns do not exist in the underlying base tables. For example, it is possible to present data summaries in a view (for example, an average), which you cannot maintain in a base table.

You can create hierarchies of views in which views can be created on views. This can be useful, but you should be aware that deleting any of the lower level views invalidates dependencies of higher level views in the hierarchy.

There are at least four reasons to use views. Views provide all of the following:

• A simplified user perception of the database.

• Security for restricting table access and updates.

• Well-defined, well-tested, high performance access to data.

• Logical data independence, which minimizes application modification if base tables need to be restructured.

The remainder of this chapter discusses the following topics:

• How to create and alter a view.

• Expanded discussion of why database administrators should use views.

• Restrictions on the updatability of some views.
Previous << 1 .. 31 32 33 34 35 36 < 37 > 38 39 40 41 42 43 .. 76 >> Next