Ch 03 OPEN SQL & NATIVE SQL - 1

R/3 Architecture

• 세개의 Layer로 분류

1. Presentation Layer
   • 개인 컴퓨터
   • SAP GUI를 통해 데이터를 입력 및 조회
   • SAP GUI는 단지 터미널의 역할
2. Application Layer
   • 모든 프로그램은 Application Server에서 구성
   • Application Layer는 여러개의 Server와 하나의 Message Server로 구성
     • Message Server는 부하가 적은 서버에 사용자가 로그인 되도록 부하 분산 역할
   • OPEN SQL 사용시 Local Buffer가 데이터베이스까지 접근하지 않고 Local Buffer에서 데이터를 읽어옴
   • Dispather는 Work Process를 적절히 분배하는 역할
3. Databas Layer
   • SAP의 모든 데이터를 데이터베이스 테이블에 저장하는 계층
   • 시스템 변수, 모든 프로그램의 소스 코드, 트랜잭션 데이터 등 저장

---

기존 프로그램과 SAP 프로그램의 차이점

• JAVA ASP와 같은 프로그램과 달리 SAP는 일반 개발자에게 데이터베이스에 직접 접속하여 데이터를 수정하는 행위를 금지하고 있음.
• 데이터 조회 권한 까지 일반 개발자에게 제한
• 이러한 제한을 통해 무결성 일관성 안정성 투명성을 보장

---

ABAP 프로그램에 사용되는 오브젝트들 (Table, View, Structure, Types 등)을 ABAP Dictionary라고 부름

이러한 오브젝트들의 정보를 MetaData, Data Definition 또는 Schema라고 정의하여 데이터 구조를 정의하고 관리하는 역할을 ABAP Dictionary가 하게 됨

---

SQL

• SQL 은 DML, DDL, DCL로 구분된다.
• ABAP 프로그램의 OPEN SQL에서는 DML만 사용 가능

SQL에는 OPEN SQL과 NATIVE SQL이 있음

1. OPEN SQL
   • ABAP언어에서만 사용 됨
   • Database Interface를 통해 NATIVE SQL로 번역 됨
   • Local Buffer 사용 가능
   • DML 만 사용 가능
2. NATIVE SQL
   • OPEN SQL로 구현 할 수 없는 쿼리 사용시

---

SELECT 구문

SELECT <LINES> <COLUMNS> ...

1. Single Line
   • 하나의 라인 값을 읽어오고자 할 때
   • WHERE 조건에 유일한 키 값이 추가되어야 하는데 여러 개의 라인을 읽어오면 임의의 라인을 반환
2. Several Lines
   • 여러개 라인 값을 읽어오고자 할 때
   • DISTINCT 를 사용하면 중복 값 제외
   • INTO 구문의 결과가 저장되는 곳이 인터널 테이블이 아닌 필드나 Work Area(구조체)일 때에는 마지막에 ENDSELECT를 사용하여야 한다. 이 때 조건에 해당하는 값을 모두 읽어 올 때까지 LOOP를 수행한다.
     • SELECT ENDSELECT 구문은 수행 될때마다 Application Server와 Database 간의 인터페이스가 수행되어 조회 후 Loop 문보다 비효율적
3. AS(Alias)
4. 동적인 SELECT 구문

---

FROM 구문

• 하나 또는 여러개의 테이블을 Join 하고 조회 할 수 있다.
• Option
  • CLIENT SPECIFIED : 자동 CLIENT 설정 해제
  • BYPASSING BUFFER : BUFFER에서 값을 읽지 않음, BUFFERING이 설정되어 있더라도 바로 데이터베이스 테이블에서 SELECT 수행
  • UP TO n ROWS : SELECT 의 row 개수 제한

---

WHERE 구문

1. Interval 조건

   SELECT ... WHERE <s> [NOT ] BETWEEN <f 1> AND <f 2>

2. String 비교

   SELECT ... WHERE COL1 LIKE 'ABC%'. "*ABC 로 시작하는 조건 SELECT ... WHERE COL2 LIKE 'ABC_'. "*ABC 로 시작하는 4자리 조건

3. LIST VALUE

   SELECT ... WHERE 거주지 IN ('서울', '수원'). "*서울 OR 수원에 거주하는 (여러) 조건에 속한 값

4. FOR ALL ENTRIES

   SELECT ... FOR ALL ENTRIES IN <itab> WHERE <cond>
   • itab의 칼럽과 비교 대상 테이블의 칼럼 타입은 같아야 한다.
   • LIKE BETWEEN IN 과 같은 비교 구문 사용 불가
   • 중복된 값은 하나만 남는다. (Unique Key 기준)
   • itab이 NULL이면 모든 데이터를 읽는다.
   • itab의 수가 많으면 그만큼 효율이 떨어짐 ( 수만큼 select문 날림 )

   (주의사항 참조 : https://m.blog.naver.com/PostView.nhn?blogId=whiteme7&logNo=110132665367&proxyReferer=https:%2F%2Fwww.google.com%2F)

5. GROUPING 구문

   SELECT <f1> <f2> [OPTION(값)] <값>... GROUP BY <f1> <f2>
   • 값들의 정보를 요약하여 조회되게 함.
   • OPTION : AVG, COUNT, MAX, MIN, STDDEV, SUM, VARIANCE

6. GROUPING 조건 : HAVING

   • GROUP BY로 조회한 구문에 그룹의 조건 추가

7. SORT 구문

   • ORDER BY를 사용하여 기술된 컬럼 기준으로 정렬
   • ORDER BY 사용하지 않으면 임의로 정렬된 결과
   • ASSENDING, DESCENDING 구문으로 정렬 사용 가능

8. Subquery

   • where 조건에 또 다른 select문 추가하여 값을 제한 목적
   1. Scalar Subquery
      • 반드시 한 칼럼만을 반환해야 한다.
      • Nested Loop 방식
      • 실행되는 횟수는 row 수
      • 반복되는 코드나 유형의 테이블에서 효율적
   2. nonScalar Subquery
      • 결과가 존재하면 True 반환
      • 결과가 없다면 False 반환
      • EXISTS 구문으로 구현

---

구조체 ( Structure )

• 테이블과 비슷하지만 차이가 있다.
• 테이터의 유무 ( 테이블은 데이터 유, 구조체는 무 )
• 개발 편의성을 위함 → 동일구조 Internal Table을 반복 사용시
• 조회문에서 * 사용하면 성능 하락, 비효율적 → 구조체 사용하여 효율적으로 할 수 있다.

(출처 : http://egloos.zum.com/yhkim0614/v/1848428 )