9.1 Programming languages

프로그래밍 언어

프로그래밍 언어는 두 가지 주요 범주 또는 패러다임으로 나뉜다: 명령형(Imperative)과 선언형(Declarative).

명령형 언어(Imperative Languages)는 프로그램 단계의 실행 순서를 결정하는 제어 흐름(Control Flow) 문을 포함한다. 제어 흐름 문에는 반복적으로 코드를 실행하는 루프(Loop)와 조건적으로 코드를 실행하는 조건문(Conditional)이 포함된다.

1. 절차적 언어(Procedural Languages): 절차(Procedures)로 구성되며, 이는 함수(Functions) 또는 서브루틴(Subroutines)이라고도 한다. 1990년 이전에 개발된 대부분의 언어는 절차적 언어이다.
   예: C, COBOL
2. 객체 지향 언어(Object-Oriented Languages): 코드를 클래스로 조직한다. 클래스는 변수와 절차를 단일 구조로 결합한다. 1990년 이후 개발된 대부분의 언어는 객체 지향 언어이다.
   예: Java, Python, C++

선언형 언어(Declarative Languages) 는 제어 흐름 문을 포함하지 않는다. 각 문은 결과를 처리하는 방법이 아니라, 원하는 결과를 논리적 표현식으로 선언한다.
예: SQL, HTML

프로그래밍 언어 유형   이 섹션의 목적은 데이터베이스 프로그래밍에 대한 배경 정보를 제공하는 것이며, 프로그래밍 언어의 완전한 분류를 제공하는 것이 아니다. 완전한 분류에는 함수형 프로그래밍(Functional Programming) 및 논리 프로그래밍(Logic Programming)과 같은 추가 범주가 포함될 수 있다.

---

데이터베이스 프로그래밍

선언형 언어는 데이터베이스 쿼리에 두 가지 이유로 일반적으로 사용된다:

1. 더 쉬운 프로그래밍:
   절차적 언어에서는 복잡한 쿼리를 루프와 조건문으로 코딩해야 한다. 선언형 언어를 사용하면 복잡한 쿼리를 단 한 문장으로 코딩할 수 있다.
2. 더 빠른 실행:
   절차적 언어에서는 프로그래머가 쿼리를 처리하는 방법을 지정한다. 선언형 언어에서는 옵티마이저가 쿼리를 처리하는 방법을 결정한다. 복잡한 쿼리는 여러 방식으로 처리될 수 있으므로, 최적화된 쿼리는 보통 프로그래머가 작성한 쿼리보다 더 빠르게 실행된다.

위의 이유와 IBM의 초기 지원 덕분에 SQL은 지배적인 쿼리 언어가 되었다.

완전한 애플리케이션은 제어 흐름 문과 데이터베이스 쿼리가 모두 필요하다. SQL은 제어 흐름 문이 없으므로, 완전한 애플리케이션은 SQL과 절차적 또는 객체 지향 언어를 결합한다. SQL과 범용 언어를 함께 사용하여 애플리케이션을 개발하는 것을 데이터베이스 프로그래밍(Database Programming)이라고 한다.

데이터베이스 프로그래밍은 다음과 같은 두 가지 과제를 제시한다:

1. 구문 차이(Syntax Gap):
   SQL과 대부분의 다른 언어의 구문은 매우 다르다.
   예: 블록(Blocks)으로 불리는 문장의 그룹은 대부분의 절차적 및 객체 지향 언어의 기본 요소이다. 그러나 SQL에는 블록 개념이 없다.
2. 패러다임 차이(Paradigm Gap):
   쿼리 처리 방식은 SQL과 절차적 또는 객체 지향 언어에서 근본적으로 다르다.
   예: SQL에서는 여러 행으로 구성된 결과 집합이 단일 SQL 문으로 처리된다. 하지만 다른 언어에서는 보통 루프와 조건문이 필요하다.

데이터베이스 프로그래밍은 이러한 구문과 패러다임의 차이를 극복해야 한다.

9.1.2:   Syntax and paradigm gaps

---

데이터베이스 프로그래밍 기법

구문과 패러다임의 차이를 극복하기 위해 세 가지 데이터베이스 프로그래밍 기법이 등장했다:

• 임베디드 SQL(Embedded SQL):
  다른 언어로 작성된 프로그램에 SQL 문을 직접 삽입한다. 모든 SQL 문 앞에 EXEC SQL 키워드가 붙어 컴파일러가 SQL을 다른 문과 구분할 수 있다.
  예: Oracle Database에서 C로 작성된 임베디드 SQL은 Pro*C라고 한다.
• 절차적 SQL(Procedural SQL):
  SQL 언어에 제어 흐름 문을 추가하여 새로운 프로그래밍 언어를 만든다.
  절차적 SQL은 범용 언어에 비해 기능이 제한적이며 주로 데이터베이스 애플리케이션에 사용된다.
  예: Oracle Database에서 절차적 SQL은 PL/SQL이라고 한다.
• 애플리케이션 프로그래밍 인터페이스(API):
  프로시저 또는 클래스의 라이브러리로, 애플리케이션 프로그래밍 언어를 데이터베이스, 이메일, 웹 서비스와 같은 컴퓨터 서비스에 연결한다.
  프로시저 또는 클래스 선언은 애플리케이션 프로그래밍 언어로 작성된다.
  예: JDBC는 관계형 데이터베이스에 접근하기 위한 Java 클래스의 라이브러리이다.

Embedded SQL은 SQL과 함께 1980년대에 개발된 가장 초기의 데이터베이스 프로그래밍 기법이다. procedural SQL은 1980년대 후반, 임베디드 SQL 이후에 등장했다. 최초로 널리 사용된 데이터베이스 API인 ODBC는 1992년에 출시되었다.

절차적 SQL과 API는 종종 함께 사용된다. 일반적인 데이터베이스 작업은 SQL 프로시저로 작성되고, 컴파일된 프로시저는 API를 통해 호출되어 여러 애플리케이션에서 재사용될 수 있다.

9.1.4: API example using C# and ODBC

1. 이 예제는 C#에 내장된 ODBC를 보여준다.  reservationConnection 객체는 프로그램을 데이터베이스에 연결한다.  
2. listFlights 객체는 SELECT 문을 포함하며, Reservation 데이터베이스에 연결된다.  
3. flightReader 객체는 결과 테이블의 개별 행을 가리킨다.  
4. ExecuteReader() 는 listFlights 객체에 저장된 SELECT 문을 실행한다.  
5. Read() 는 flightReader 를 결과 테이블의 다음 행으로 이동시킨다. while 루프는 모든 행을 읽을 때까지 반복된다.  
6. GetInt32(0) 과 GetInt32(1) 은 현재 flightReader 행의 첫 번째 열과 두 번째 열 값을 반환한다.

---

장점과 단점

임베디드 SQL은 프로그래머가 다른 프로그래밍 언어 내에서 SQL 문을 직접 작성할 수 있게 한다. 이 접근 방식은 개념적으로 간단하지만, 세 가지 문제가 있다:

• Gaps: 현재 대부분의 프로그래밍은 객체 지향 언어를 사용한다. 객체 지향 언어와 SQL 간의 구문 및 패러다임 격차가 크기 때문에, 프로그램 작성 및 유지 관리가 어렵다.
• Compile steps: SQL 문과 호스트 언어는 각각 다른 컴파일러로 두 단계에 걸쳐 컴파일해야 한다.
• Network traffic: 애플리케이션 프로그램은 일반적으로 클라이언트 컴퓨터에서 실행되며, 네트워크를 통해 데이터베이스 서버와 연결된다. 임베디드 SQL을 사용하면 각 쿼리가 클라이언트에서 서버로의 '왕복'을 생성하여 네트워크 트래픽과 실행 시간이 증가한다.

이러한 이유로 임베디드 SQL은 더 이상 널리 사용되지 않는다.

절차적 SQL은 임베디드 SQL에 비해 몇 가지 장점이 있다:

• Gaps: 절차적 SQL은 SQL을 확장하여 구문 및 패러다임 격차를 최소화한다. 따라서 프로그램 작성 및 유지 관리가 비교적 쉽다.
• Compile steps: 절차적 SQL은 두 단계가 아닌 한 단계에서 컴파일된다.
• Network traffic: 클라이언트 애플리케이션은 일반적으로 데이터베이스 서버에서 실행하기 위해 SQL 프로시저를 호출한다. 각 프로시저는 여러 데이터베이스 작업을 실행하여 네트워크 트래픽과 실행 시간을 줄인다.
• Optimization level: 데이터베이스는 개별 쿼리가 아니라 전체 프로시저를 최적화하므로, 더 나은 최적화와 빠른 쿼리 실행을 제공한다.

그러나 절차적 SQL 언어는 데이터베이스마다 크게 다르며, 범용 언어의 모든 기능을 제공하지 않는다.
Ex: 대부분의 절차적 SQL 언어는 객체 지향적이지 않다.
이러한 이유로, 절차적 SQL은 제한된 데이터베이스 작업에 주로 사용된다.

 

API는 임베디드 SQL과 절차적 SQL의 한계를 극복한다:

• Gaps: API 프로시저와 클래스 선언이 애플리케이션 언어로 작성되므로, 애플리케이션은 한 단계에서 컴파일되고 구문 격차가 사라지며 패러다임 격차도 줄어든다.
• Applications: 데이터베이스 API는 범용 객체 지향 언어에서 사용할 수 있다. 따라서 애플리케이션은 데이터베이스 처리 작업과 절차적 언어에 국한되지 않는다.
• Database independence: 절차적 SQL과 달리, 언어와 API 구문은 데이터 소스와 독립적이다.

위와 같은 이유로 API는 가장 일반적으로 사용되는 데이터베이스 프로그래밍 기술이다.

Table 9.1.1: Advantages and disadvantages.

	Paradigm gap	Syntax gap	Object-oriented language	Applications	Compile steps	Network traffic	Database- independent
Embedded SQL	High	High	Limited	General	2	High	No
Procedural SQL	Moderate	Low	Limited	Database processing	1	Low	No
API	Moderate	Low	Yes	General	1	Variable	Yes