5.1 Embedded SQL

  정의: Program내에 Embed 된SQL 구문 및 SQL 구문내의 DB Object (컬럼 이름 등)가 어플리케이
        션 실행전인 개발시에 미리 정의된 형태의 SQL 구문 형식
	
        SQL 구문에 의해서 수행되는 작업 (조회 및 수정)시 필요한 data 값 (host variable)
        만이 어플리 케이션 개발시가 아닌 실행시에 지정되어 그 값에 따라 SQL 구문이
        수행된다.


  특징 
   1. 어플리케이션의 precompile, bind 과정이 필요하다. 
      bind 과정중에 DB object에 대한 type, syntax, previlege checking이 이루어지므로, SQL
      구문에 정의된 DB Object는 어플리케이션 bind시에 반드시 DB내에 존재하여야 한다.


   2. Package를 미리 생성하며, 이는 DB2에 의해서 저장되고 관리된다.
      어플리케이션 bind후 DB내에 Package가 생성되며, 어플리케이션 실행시, 앞서 bind 과정에
      서 생성된 Package의 접근 경로 (access plan 또는 access path)을 이용하여 해당 SQL의 
      최적화된 수행이 이루어진다.
          
      Dynamic Embedded SQL 어플리케이션이 매번 실행시마다 Package를 작성해서 SQL구문을 처
      리하는 것에 비해 미리 bind 과정에서 작성된 Package를 바로 사용함으로써, Package 작성
      에 필요한 overhead를 덜수 있다.
	
   3. Bind 과정은 최초 한번만 필요하나, 상황에 따라 정기적으로 rebind를 수행할 수 있다.
   4. 반복적이고 정형화된 업무 (예약, 잔액 조회등)와 같은 사전에 정의된 (pre-defined) 트랜
      잭션 형태의 어플리케이션 구현에 적합하다.


   장점
   1. 사전에 Package를 작성해서 사용하므로, 실행 속도가 빠르다.
   2. 어플리케이션 실행시가 아닌, 개발시에 DB object에 대한 사전 검사가 가능하다.


  단점
   1. 개발시에 SQL 구문이 정의되어 있어야 한다.
   2. Precompile, bind 과정이 필요하다.

   정의: Program내에 Embed 된 SQL 구문이 어플리케이션 개발시가 아닌, 실행시에 정의되어
         (완성되어) 처리되는 SQL 구문 형식


   특징
   1. Bind 과정이 필요없다. 
      Static Embedded SQL의 경우처럼 미리 bind 과정을 거쳐 미리 Package를 생성하는 것이 
      아니라, 어플리케이션 실행시에 SQL 구문이 완성되어 DB내에 Package를 만들어, 이 
      Package내의 access plan을 이용한다.
   2. 어플리케이션 실행 시점의 (current) DB2의 통계 정보를 기초로한 Package가 작성되므로, 
      매번 실행시마다 최적화된 access plan이 제공된다.
	
      Static SQL의 경우, bind 과정에서 미리 생성된 Package는 bind time시의 DB2 통계정보를
      근거로 작성되므로 실제 어플리케이션 실행 시점의 통계정보와 차이가 날 수 있다.
      따라서, 이러한 상황을 방지하기 위해 주기적으로 DB2 통계정보 갱신을 위한 RUNSTAT 작업
      및 어플리케이션 Rebind를 수행한다. (5.3 Application Rebind 참조)

   3. 실행시 생성된 Package는 DB2에 의해서 관리되지 않는다. (dummy Package)
   4. Embedded SQL이므로 precompile 과정이 필요하다.


   장점
   1. 어플리케이션 내 각 SQL 구문에 대해 가장 최근 시점의 통계정보를 근거로한 access plan
      을 가질 수 있다.
   2. SQL 구문은 개발시가 아닌, 실행시에 확정되므로, 보다 다양하고 유연한 어플리케이션 개
      발이 가능하다.


   단점
   1. 실행시마다 Package를 작성해야 하는 overhead로 Static에 비해 처리 속도가 느리다.
   2. 실행전에 SQL 구문의 type, syntax, previlege checking 이 불가능하다.


   참고) DB2의 Package는 해당 SQL을 DB2의 해당 DB내에서 처리하기 위한 최적의 방법인 access
         plan을 가진다. 이 access plan은 DB2의 System catalog 정보를 근거로한 DB2 통계정보
         를 근거로 DB2 Optimzier에 의해서 생성된다. Static 및 Dynamic SQL의 가장 큰 차이점
         은 이 Package 생성 시점 및 관리 여부의 차이가 된다. 

   설명
    1. Embedded SQL 구문이 포함된 프로그램의 Source File을 작성한다.
    2. DB에 connect 하여, 각 Source File을 precompile한다.
       precompiler는 embedded SQL 구문을 여라 다양한 API request로 바꿔주는 역할을 하며,
       precompile 과정을 통해 bind file을 생성하거나, 직접 DB에 Package를 생성할 수 있다.
    3. 변경된 Source File을, 작성한 language compiler를 이용하여 compile한다.
    4. Object File을 DB2 및 language Library에 link하여 실행 프로그램을 생성한다.
    5. DB에 connect한 후, 2의 과정에서 생성된 bindfile을 DB에 bind 시킨다.
       이는 DB에 Package를 생성하기 위해서이며, 2 과정의 precompile 옵션을 이용해 직접
       Package를 생성하였으면 수행할 필요가 없다. 그러나 다른 DB에 같은 내용의 Package를 
       생성하고자 할 때, 같은 bindfile을 이용한다.
    6. 생성된 어플리케이션을 실행한다.
       이 어플리케이션은 앞서 생성된 DB의 Package를 사용하여 SQL 구문을 처리한다.

    정의: DB2의 Package는 최적화된 SQL 구문을 담고 있는 DB object이다. 하나의 프로그램
          source는 하나의 Package에 대응되고, Program Source내의 SQL 구문은 Package내의
          Section에 대응된다.
  
    특징
    1. 구조: Static Embedded SQL Program은 default로 precompile 과정을 통해서 연결된 DB내
             에 Package를 생성한다. Section은 compile된 형태의 SQL 구문이며, Package 내에
             는 각 Embedded SQL 구문에 대응되는 여러 Section을 가진다. 각 Section 내에는
             하나의 SQL 구문에 대응되어, SQL 구문과 이 SQL 구문에 대한 최적화된 access 
             plan이 section 내에 저장된다. 이렇게 생성된 Package는 직접 DB에 저장되거나,
             또는 Package 생성 모듈이 bindfile내에 저장되어, 별도의 bind 과정을 거쳐서 DB
             에 Package를 생성한다.

     2. Dynamic Embedded SQL 어플리케이션의 Package
        Dynamic Embedded SQL 구문의 경우, 마찬가지로 precompile - bind 과정을 거쳐서
        Package를 생성하나, Section내에 access plan이 없는것이 Static과의 차이점이다.

     3. Package 실행 특권
        생성된 Package내의 SQL 구문을 실행하기 위해서는 사용자가 Package에 대해 Execute
        특권이 있어야 한다. 이는 SQL 구문내의 DB object에 대한 직접적인 권한 없이도 직접
        SQL 구문을 수행하는 것과 같은 동일한 효과를 가진다.

정의 : Bindfile은 Static Embedded SQL 구문에 대한 Package 생성 정보를 담은 file이며, 
       bindfile을 이용하여 DB에 Package를 생성하는 과정
	
특징 
1. DB2 Package 생성은 precompile 과정에서 직접 DB에 생성되거나 (bindfile option), 
   bindfile을 만들어 나중에 bind 과정을 거쳐서 DB에 생성할 수 있다. 이를 "deferred 
   binding"이라 한다.

2. Static Embedded SQL 어플리케이션에만 적용되는 과정이다.
   어플리케이션이 접속되는 DB에 한번만 bind하면 되며, 추후의 bind 작업은 "Application
   Rebind" 과정을 통해 마찬가지로 bind 한다.

3. Package 및 Bindfile과 SQL 어플리케이션 실행 File은 같은 내용의 Consistency Token 
   (Timestamp 정보)를 가진다.

   Bindfile에 의해서 Package 생성시, 생성시점(timestamp)에 대한 정보(consistency token)
   가 Package내에 저장된다. 이와 똑같은 내용의 consistenty token이 DB의 system catalog 및
   어플리케이션 실행 모듈에 저장되어, SQL 어플리케이션이 SQL 구문을 수행할 때, 그에 맞는
   Package내의 access plan을 이용할 수 있도록 한다.

4. Bind시 필요한 권한 및 특권
   Bind 작업을 수행하는 사용자는 최소한 "BINDADD" 권한이 있어야 하며, IMPLICIT_SCHEMA,
   CREATEIN" 특권이 있어야 한다. 따라서 이러한 권한을 가진 Group의 사용자로 어플리케이션
   개발자 권한을 grouping한다. 또한 static SQL이 reference하는 모든 DB object에 대한 적절
   한 특권이 있는 사용자여야 하므로, 이러한 DB object에 대한 특권은 명시적으로 사용자에게
   grant 되거나 PUBLIC으로 선언되어야 한다. 
   (group에만 grant 되었을 경우 bind시 fail이 난다.)

5. Blocking Factor
정의: Record Blocking은 대용량의 데이타를 처리하는 어플리케이션의 네트웍을 통한 데이타 접
      근 속도를 향상시켜주기 위한 데이타의 네트웍 이동에서의 DB2 데이타처리 방식이며, 이러
      한 Record Blocking은 어플리케이션 bind시 Blocking Factor (bind option)에 의해서 지정
      된다.

특징: Record Blocking은 Cursor type 및 Record Blocking을 수행할 DB2 Server의 storage 량에
      따라 결정된다.

      multiple Row로 구성된 Result Set의 처리는 Cursor를 통해 이루어진다. Cursor type에 대
      한 Blocking Factor는 UNAMBIG, ALL, NO 가 있다.
			
      UNAMBIG : FOR UPDATE cursor를 제외한 모든 cursor는 blocking된다.
      ALL     : 모든 cursor가 blocking된다.
      NO      : 어떠한 cursor도 blocking 처리되지 않는다.	

      DBM cfg의 ASLHEAPSZ 파라미터로 multiple data record를 요청하는 어플리케이션에 대해
      DB2 Server에서의 data buffer에 사용되는 memory 할당량을 지정한다.      
      (DB Server의 memory 할당) 또한, 원격 SQL 어플리케이션에서의 memory 할당은 DBM cfg의
      RQRIOBLK값으로 지정한다.
		
 참고) CLI 어플리케이션 및 DB2 CLP (Command Line Processor)의 Blocking Factor의 default 
       값은 UMAMBIG이며, 이를 변경하고자 할 경우에는 각각의 bindfile (db2cli.bnd,
       db2clp.bnd)를 bind 할 때, bind option을 지정하여 수행하면 된다.

5.2 DB2CLI (Call Level Interface) & ODBC

정의: DB2CLI는 C 및 C++ 언어를 이용한 DB2 Programming Interface의 하나이다.

특징
1. DB2CLI는 Microsoft의 ODBC 및 X/Open, ISO Call Level Interface Standard를 기초로 구성되었
   다. 
   따라서, DB Vendor와 상관없이 ODBC 및 X/Open의 CLI를 지원하는 DBMS 모두에서 사용할 수 있는
   portable 어플리케이션 개발이 가능하다. 

 
   참고) DB2 ODBC Driver는 MS의 ODBC 2.0의 Level 2 및 ODBC 3.0의 Level 1의 모든 spec, Level
         2의 대부분의 spec에 따라 개발되었다.
 
         DB2CLI는 ODBC를 기초로하므로,  상호 호환적인 관계에 있다. 따라서 C나 C++ 언어 
         (MS Visual C++)를 이용한 CLI 어플리케이션 또는 MS Visual Basic 및 PHP, Python, Perl
         과 같은 script Language를 이용한 ODBC 어플리케이션 개발 및 실행은 각각 DB2 CLI
         ODBC Driver에 의해서 처리되며, 각 Driver의 내용 및 Driver 및 DB2 기능은 거의 비슷하
         다.


2. DB2CLI는 Dynamic 어플리케이션 개발 방식이다. (bind 및 Package 생성 불필요)
   따라서, Dynamic Embedded Application과 마찬가지로 별도의 bind 과정이 필요없으며, Packagae
   생성은 어플리케이션 실행시에 이루어진다. CLI 어플리케이션은 DB2에 의해서 제공되는 공통적
   인 access package를 이용하여 실행되므로 개별 어플리케이션의 bind 과정은 필요없는 대신에
   공통적으로 DB2CLI package를 해당 DB에 한번 bind하여 DB2CLI 또는 ODBC 어플리케이션이 이를
   사용할 수 있도록 한다.


   CLI 어플리케이션의 (Embedded) Dynamic SQL 어플리케이션과의 차이점

   • Precompile 과정이 없다. (따라서 bind 및 Package 생성이 없다)
      어플리케이션 level의 Package가 없는 대신, 모든 CLI 어플리케이션이 공통적으로 이용하는
      CLI Package들을 해당 DB에 한번만 bind한다.
   • 명시적인 cursor 정의가 없다.
   • Commit/rollback 구문대신 SQLEndTran() Fuction을 사용한다.
   • SQLCA / SQLDA 와 같은 DB에서의 특정 error 처리 API가 없다.
   • Host variable 대신에 parameter marker를 사용한다. 또한, 다음의 제약 사항을 가진다.
   • multiple Row 처리를 한번에 수행할 수 없다. (array fetch/ insert)
   • scrollabel cursor가 지원되지 않는다.
	
3. CLI 및 ODBC의 Dynamic SQL 구문은 Program에 embedded 되지 않고, DB2에 의해서 제공되는
   C/C++ API를 이용하여 function argument의 형식으로 DB2에 전달된다 
   (direct API call). 따라서, Program precompile 과정이 불필요하다.

4. Embedded SQL 구문에서 SQL 수행 성공 여부를 검사하는데 사용하는 SQLDA 및 SQLCA를 사용하지
   않으므로 어플리케이션 작성이 쉽다.

장점
1. Precompile, bind 과정이 필요없다. 
2. 어플리케이션 실행시에 DB2의 통계정보를 기초로한 access plan을 이용할 수 있다.
3. 다른 DB platform에 쉽게 이식할 수 있다.

단점
Static Embedded SQL과 비교하여 어플리케이션 실행 속도가 느리다.
(Dynamic Embedded SQL과 공통)

   ODBC와 CLI의 비교
   • Commit CLI 어플리케이션은 아키텍쳐상 ODBC Driver Manager없이 어플리케이션이 직접 CLI
      Driver와 통신한다.
   • DB2 ODBC Driver 및 DB2 Data Source는 반드시 ODBC Driver Manager에 등록되어야 하나,
      CLI Driver는 DB2 Client만 설치되면, 별도의 등록 과정이 필요없다.
   • ODBC는 Windows 및 Linux 환경에서만 사용할 수 있으나, CLI는 UNIX를 포함한 보다 다양한
      환경 및 C/C++, Java와 같은 강력한 프로그래밍 언어를 지원한다.

1. DB2 SDK를 설치하고, DB2 CLI Library를 확인한다. 
   Windows 환경 : sqllib \ lib \ db2cli.lib
   UNIX 환경 : sqllib / lib / libdb2.a 또는 libdb2.so
2. 접속하고자 하는 DB가 원격일 경우, 어플리케이션 client에 Node 및 DB cataloging을 한다.
3. DB2 CLI bindfile들을 접속할 DB에 bind한다.
   다음의 디렉토리에서 접속하고자 하는 DB2 서버의 종류에 따라 다음의 file들을 bind한다.

sqllib / bnd / db2cli.lst      ( DB2 UDB )
               dd  csmvs.lst   ( DB2 for OS/390 ) 
               ddcs400.lst     ( DB2 for OS/400 )

  참고) .lst File은 bindfile들을 모아놓은 list file이며 list file의 bind는 다음의 예와 같
        이 file 앞에 "@"문자를 추가하여 사용하면 된다.
	
  예) "db2 bind @db2cli.lst blocking all isolation cs grant public messages db2cli.msg"
      "db2 bind @ddcsmvs.lst blocking all sqlerror continue grant public"

4. 필요에 따라, db2cli.ini File의 내용을 편집하여 CLI 환경 구성을 수정한다. 
   가장 많이 사용되는 option은 다음과 같다.

   1. DB2 Client를 설치하고, 접속하고자 하는 DB가 원격일 경우, Node 및 DB cataloging 작업
      을 수행한다.
   2. ODBC Driver Manager가 설치되었는지 제어판에서 확인하고, DB2 Data Source를 System
      DSN 또는 사용자 DSN으로 등록한다.

      참고) DB2 ODBC Driver ("IBM DB2 ODBC Driver")는 DB2 Server 또는 client 설치시에 자동
            으로 설치 및 등록된다.

   3. ODBC 환경 설정은 DB2 CLI와 마찬가지로 db2cli.ini File을 편집하여 적절할 환경 구성을
      설정한다.

CLI 및 ODBC에 대한 보다 자세한 내용은 DB2 Manual인 "DB2 CLI Gude and Reference" 및 "ODBC 
Guide & Reference"를 참조한다.

5.3 Java Interfaces (JDBC / SQLJ)

정의: JDBC 및 SQLJ 는 DB2에서 Dynamic SQL 및 Static SQL을 처리하기 위한 Java Programming
      Interface이다.


특징

1. JDBC 및 SQLJ는 vendor-independent한 Java Language의 SQL interface이다.
2. JDBC는 DB2CLI의 경우처럼, API Call로써 SQL 구문이 처리하며, Dynamic SQL 처리 방식의 특성
   을 가진다. SQLJ는 SQL 구문이 프로그램상에 Embedded되어, Static SQL의 방식을 따른다.

3. JDBC 와 SQLJ의 비교

DB2 UDB는 2가지 형태의 JDBC Driver를 제공한다. (sqllib/java/db2java.zip)
  App Driver: COM.ibm.db2.jdbc.app.DB2Driver - DB2 Client가 어플리케이션 클라이언트에 설치
              되어 있을 경우 사용한다. (Java Application)
  Net Driver: COM.ibm.db2.jdbc.net.DB2Driver - DB2 Client가 없을 경우 사용한다.
              (Java Applet)
  참고) Java Servlet의 경우도 DB2 Client 설치 여부에 따라 Driver를 선택하여 사용한다.

sqlj (SQLJ Translator): precompiler와 마찬가지로 Java Source code에서 Static Embedded SQL
구문을 precompile하여 수정된 java file (.java)과 Serialized profile (.ser) 을 생성한다.


javac (Java Compiler): 수정된 java source code를 compile하여 실행 class와 ProfileKey class
를 생성한다.


db2profc (DB2 Profile Customizer): SQLJ Translator에 의해서 생성된 Serialiezed Profile을
customzation하여 DB에 직접 Package를 만들거나 또는 bindfile을 생성한다.


SJProfileKeys.class File: 실행 java class와 DB2 DB내의 Package를 연동시켜주는 역할 
(consistency token)을 수행한다.


참고) 1. SQLJ 어플리케이션은 DB2의 일반적인 Static Embedded SQL 어플리케이션의 모든 특징을
         가진다.
      2. SQLJ Translator (sqlj.zip)은 DB2 SDK에 포함되며, SQLJ 어플리케이션 개발시에만 필
         요하다. 작성된 SQLJ 어플리케이션 (Java Application, Applet, Servlet)의 실행환경
         에서는 필요없으며, 대신 db2java.zip (DB2 JDBC Driver File) 및 runtime.zip (SQLJ
         어플리케이션 실행 환경 File)만이 사용자 profile의 classpath에 등록되어 있으면 된
         다.

5.4 MS Data Objects (DAO, RDO, ADO, OLE-DB)

5.5 Data Locking Strategy

5.6 Application Rebind

5.7 DB2 Stored Procedure 작성