ODBC 와 JDBC 를 통한 데이터로의 접근

ODBC (Open Database Connectivity) 와 JDBC (Java Database Connectivity) 는 데이터베이스로 접근하는 미들웨어의 한형태이다. 넷트워크 관리자의 관점에서 보면 그들은 클라이언트와 서버 드라이브 소프트웨어로 구성되어 있다. (즉 프로그램 파일들). 프로그램머의 관점에서 보면 프로그램머가 데이터베이스로 자료를 저장하고, 추출해 내기 위해서 그의 프로그램 내에 삽입해야 하는 API (응용프로그램 인터페이스) 이다. 반면에 시스템 분석가는 ODBC 나 JDBC 를 응용프로그램과 데이터베이스 사이의 개념적인 연결로서 받아 들인다. 데이터베이스 벤더들은 그들의 독점적인 인터페이스 보다는 ODBC 나 JDBC 와 같은 표준 인터페이스를 그들의 고객들에게 제공해 주는 것이다. 데이터를 처리하는 부서의 관리자는 ODBC 나 JDBC 를 일종의 보험으로서 여긴다 -- 이것은 하나의 데이터베이스 제품을 다른 것으로 대체하고자 할때 많은 유연성을 제공해 준다는 것을 의미한다.

Network Computing's Network Design Manual 의 이번 장에서 여러분들은 ODBC 와 JDBC 를 각각의 관점에서 살펴 볼것이다. 여러분들은 왜 ODBC 와 JDBC 가 중요한지를 알게 될 것이며, 어떻게 이런 인터페이스들이 동작하는지 알게 될 것이며, 어떻게 여러분들의 회사에서 ODBC와 JDBC 를 가장 이상적으로 이용할수 있는지를 알게 될 것이다.

데이터베이스로 접근하기 위해서 응용프로그램들은 다양한 접근 방법들로-- ODBC, JDBC, OLE DB, ADO, DAO, RDO, Oraclqe Objects for OLE, gateways, 독점적인 원래의 API 들 (OCI 나 DBLib 등과 같은), data-aware component, 그리고 다양한 다른 해법들 -- 혼란만 초래하게 된다.

데이터베이스로 접근하기 위한 미들웨어

데이터베이스로 접근하기 위한 middleware 들은 컴퓨터 응용프로그램과 데이터베이스 사이에 정형화된 접속 방법을 제공한다. 이들 정형화된 접속방법이란 우리들은 이미 형식을 잘 갖추고, 이미 알려진 정의(definition,함수정의를 말한다)들을 통해서 연결함을 의미한다. 이 정의는 응용프로그램이 데이터베이스로 SQL문을 보내고 그 연결을 통해서 데이터베이스 내용을 받는 데 이용할 수 있어야 한다. ODBC 와 JDBC 의 경우, 이러한 정의들은 ODBC 와 JDBC 가 데이터베이스로 접근하기위한 미들웨어의 산업표준이기 때문에 모든 밴더들에게 동일하다. ODBC 와 JDBC 는 다른 많은 플랫폼에서 이용가능하고, 서로 다른 데이터베이스 시스템들 사이에서 동일한 인터페이스를 제공하기 때문에 중요하다.

일처적으로 데이터베이스 접근 미들웨어는 SQL 구문과 데이터베이스 내용을 응용 프로그램들과 데이터베이스 시시템 간의 왕복하는 버스 역할을 한다. 게다기 이들은 보안을 견고히 해주며, 직접적으로 데이터베이스 서버를 다루어야 할 필요성을 없애 준다. 데이터베이스 접근 미들웨어들의 일반적 질의 툴들은 (데이터베이스 그 자체보다) 데이터베이스 제품들의 여러가지 형식들을 위한 질의 서비스를 제공한다. Viusal Basic, C, C++, Pascal, COBOL 또는 다른 많은 언어들로 작성된 컴퓨터 프로그램은 ODBC 를 통해서 데이터베이스 작업을 할수 있다. Java 로 작성된 유사한 프로그램들은 JDBC 를 통해서 데이터베이스 작업을 실행할 수 있다. ODBC 나 JDBC 를 이용하는 프로그램들은 데이터베이스 서버 컴퓨터 상에서 직접적으로 동작할수 있으며, 그러나 보다 전형적으로는 그들은 넷트웍킹이 되어 있는 데이터베이스 서버 컴퓨터 로 클라이언트로 부터 접근할 수 있다.

ODBC 를 지원하는 밴더들은 많다. JDBC 지원은 아직 ODBC 지원 만큼 원활하지 못하다. 그러나 JDBC 는 계속 커지고 이용이 많아 지고 있다. 데이터베이스 제품 밴더들과 제 3차 소프트웨어 개발 업체들은 여러가지 데이터베이스 시스템과 다양한 운영체제 상의 ODBC 와 JDBC 드라이브들을 출시하고 있다. 부록에 ODBC 와 JDBC 미들웨어 개발 밴더들의 리스트를 적어 놓았다.

다음에서 논의하는 것은 데이터베이스 접근용 미들웨어들에 대한 기본적인 사항들과 ODBC 와 JDBC 에 관한 특수한 정보를 제공하고 있다. 여러분들은 어떻게 SQL 구문을 데이터베이스 서버로 전달하는지, 서로다른 데이터 접근형식을 해부하고, ODBC 의 목적을 이해하고 획득할 수 있으며, 여러분들의 회사에서 ODBC 를 사용할지 여부를 고려하는 방법을 배울 수 있으며, 그리고 ODBC 를 어떻게 효율적으로 이용할수 있는지를 발견할 수 있을 것이다. 게다가 여러분들은 JDBC 의 목적에 관해 알수 있으며, JDBC 를 선택하는데 필요한 고려사항들을 해부할수 있으며, 네가지의 다른 JDBC 드라이브 형식을 배우며, 그리고 어떻게 JDBC 를 효율적으로 이용할 수 있는지를 배우게 될 것이다.

[img]

데이터베이스로 접근하기 위한 미들웨어의 기본

SQL 표준에는 응용프로그램들이 어떻게 데이터베이스의 내용들을 저장하고 호출하는지에 대한 구문들을 정의하고 있다. 그러나 데이터베이스로 어떻게 접속하는가 하는 단계들에 대해 설명하고 있지는 않다. 그리고 데이터베이스 서버로 이러한 명령어들을 어떻게 전달하는가에 대한 정의 또한 없으며, 데이터베이스의 내용을 어떻게 데이터베이스 서버로 전달하고 또는 데이터베이스 서버로 부터 전달 받는지에 대한 설명도 없다. ODBC 가 나오기 이전에 컴퓨터 프로그램머들은 데이터베이스 제품을 출시하는 밴더들이 제시하는 방법을 따라야 했으며, 이것은 밴더들에 따라서 너무나 상이했다. ODBC 와 JDBC 를 사용하고 나서 부터는 응용프로그램들은 데이터베이스 서버로 SQL 명령어를 전달하기 위해서 데이터베이스-중립 적인 방법을 가지게 되었다. 독점적이던 또는 표준적인 인터페이스를 사용하던지간에, 클라이언트와 데이터베이스 서버간에 파이프라인 역할을 제공하는 데이터베이스로 접근하기 위한 미들웨어의 기본은 동일하다. 그리고 이것은 상당히 단순한 방식으로 동작한다.

넷트워크 환경에서 SQL 요청과 데이터베이스의 응답 내용 둘다의 전달 과정은 넷트워크 프로토콜의 일종이다. 데이터베이스 서버로 접속하고 SQL 을 보내며, 데이터베이스 소프트웨어 드라이브 프로그램과 상호작용에 의해 그 결과를 호출하는 응용프로그램이 각각의 클라이언트상에서 동작중이어야 한다.

데이터베이스로 접근하는 미들웨어의 전달 메카니즘이 응용프로그램으로 부터 SQL 을 받아 들인다. SQL 을 받아 들이는 과정에서 전달 메커니즘은 데이터베이스 서버와 응용프로그램간의 인터페이스를 통해서 이루어지게 되며, 데이터베이스 서버 컴퓨터상에서 응용프로그램이 실행되어 직접적으로 데이터베이스 소프트웨어를 취급하게 된다. 그러나 이런 전달 메커니즘은 실제 데이터베이스 서버로 SQL 을 전달하고, 그 결과를 받아 들이는 어떤 agent 처럼 동작하게 된다. 각각의 응답에 대해서 전달 메커니즘은 다시 응용 프로그램으로 결과를 전달하기 위해서 database server interface 를 이용하게 된다. Software agent 가 recipient 에게 갈 정보를 가로채고, 그 서버에 의해 가공될 정보를 넷트워크 로 보내고자 할 때 agent 는 rediretion 을 사용하게 된다.

데이터베이스 서버상에서 프로그램은 SQL 요청 메시지를 클라이언트로 부터 듣게 되며, 각각의 요청 메시지들을 SQL database call 로 전달하게 되며, database server software 는 SQL 을 가공하게 된다. 그리고 database software 의 결과는 넷트워크를 통해서 클라이언트에게 전달되게 된다. 이리하여 데이터베이스 content 는 응용프로그램에게 전달되어 그 처리를 계속하게 되는 것이다.

이제 관점을 database access middleware 의 내부 동작 과정에서 관리자의 측면으로 옮겨 보자. 각각의 클라이언트 컴퓨터 상에서 동작중인 database access middleware 는 관리자에 의해서 프로토콜 스택에 설정되어져야 하며, 전형적으로 모든 클라이언트들은 동일한 버전의 middleware 가 동작중이어야 한다. 일단 관리자가 서버 컴퓨터상에 Database vendor 들의 소프트웨어를 설치했다면 (예를 들면 Oracle 회사...), 다음으로 각각의 클라이언트 컴퓨터로 SQL 전달을 위한 드라이브를 설치해야 한다. 그런 다음에, 매 순간 클라이언트와의 넷트웍 연결이 되기도 하고 끊기도 하는 것이다.관리자는 드라이브 소프트웨어를 설치 또는 제거하는 유지보수 작업을 해야한다. 데이터베이스 밴더들로 부터 새로운 버전의 소프트웨어 드라이브가 출시 되면 이것을 주기적으로 계획을 세워 설치해줘야 한다.밴더들은 버그픽스 등을 통해 질적인 향상을 꽤햐야 하며, 관리자는 항상 새로운 드라이버 프로그램으로 변경하기 전에 테스트를 먼저 선행해야 한다.

데이터베이스 접근을 위한 다양한 방법들

응용프로그램을 디자인하는 사람들은 클라이언트로 부터 데이터베이스 서버로 접속하기 위해서 다양한방법을 사용해 왔다. 이들ㅇ 접근볍에는 custom-written (home-grown) desing, database vendor (proprietary) database access drivers, ODBC, JDBC 그리고 object-oriented technologies 등이 포함되며, 이것으로 응용 프로그램에서 SQL 구문을 실행시키고, 따로 저장공간에 저장할 필요없이, 데이터베이스의 내용을 지속적인 객체로서 사용할수 있도록 해 준다.

가장 오래되었고, 노동집약적인 접근법은 home-grown 방식이다. 이것은 ODBC, JDBC 또는 상업적으로 이용가능한 데이터베이스 미들웨어들을 전혀 사용하지 않은 방법들이다. 이런 접근법은 클라이언트 컴퓨터에서 프로토콜 스택 내에 transport layer 를 포함해야 함을 의미하며, 다른 것은 아무것도 필요없다. In-house programming staff 는 요구를 전달하고, 넷트워크상에서 반응하는 프로그램을 클라이언트와 서버 둘다 개발해야만 한다. 응용프로그램은 transport layer (TCP/IP, IPX, SNA 또는 NetBEUI)를 통하여 넷트워크 메시지를 주고 받으며, 그 프로토콜에 적절한 프로그래밍 인터페이스 (WinSock 나 NetBIOS 등)를 사용한다. 응용 시스템 설계자는 전체적인 레이아웃을 명시하고, 각각의 넷트워크 메시지의 의미를 명시해야 한다. 그리고 모든 메시지 명세서는 합쳐서 넷트워상의 대화(dialog)를 가능하게 된다. dialog 의 framework 내에서 클라이언트 응용프로그램은 넷트워크 메시지를 서버측 응용프로그램에게로 보낸다. 서버측 구성요소는 클라이언트가 요구하는 일을 하게 되며, 이는 기존의 명세서대로 따르게 되며, 그 반응 결과를 클라이언트에게 되돌려 준다. 이런 방법을 사용하는 응용 프로그램은, 넷트워크를 통하여 직접적으로 동작을 하며, 범용 미들웨어들을 통하지 않기 때문에 상당히 빠르며, 메모리를 적게 차지 한다. 다른 한편으로 TCP/IP 와 같은 transport layer 를 통하여 메시지를 주고 받는 것은 특별히 어렵지는 않다. dialog 를 설계하고 응용 프로그램에서 주고 받는 도중에 다른 일들도 추가로 삽입하는 것은 상당히 복잡하고, 에러를 만들기 쉽다. 넷트워크 관리자는 일반적으로 home-grown approach 를 더 좋아하는데, 그 이유는 드라이브 파일을 배포할일이 적으며, 클라이언트 사양을 설정할 일이 적기 때문이다.

좀더 전형적인 접근 방법은, 응용프로그램이 SQL 명령어를 보내고, 결과를 전달받는데 있어서, 데이터베이스 밴더들이 제공하는 함수호출 수준의 인터페이스를 사용하는 것이다. 그리고 밴더들이 제공하는 데이터베이스 접근 미들웨어는 SQL 과 데이터베이스 내용을 서로 주고 받는 통로 역할을 해 준다. 예를 들면, 오라클의 call-level interface 는 Oracle Call Interface (OCI) 로 불리며, 반면에 가장 잘알려진 데이터베이스 접근 미들웨어 전달 메커니즘은 SQL*Net 이다. 다른 일반적인 밴더 인터페이스는 연관된 데이터베이스로의 접근하기위한 미들웨어 제품들은 Sybase 의 Open Client, Informix Software 의 I-Net, CA-OpenIngres 의 Ingres Net, PROGRESS 의 Progress Clent Networking, Microsoft 사의 SQL 서버의 DBLibrary, IBM 사의 DB2 를 위한 DDCS 등이 있다.

표준이 되지 못한 데이터베이스 접근 API (적어도 아직까지는) 에는 IBM's Distributed Relational Database Architecture (DRDA), Microsoft's Data Access Objects (DAO) and Remote Data Access (RDA), 그리고 Oracle's Objects for OLE (formerly Oracle Glue) 등이 포함된다. DAO 와 RDA 는 요구와 반응 결과를 ODBC call 로 전달하는 high-level, object-oriented API 들이다. Oracle Objects for OLE 는 클라이언트 프로그램이 Microsoft OLE 표준을 이용하여, Oracle7 과 Oracle8 데이터베이스로 직접적으로 접근할수 있도록 허용하는 미들웨어 제품이다. 이것은 세가지 구성요소로 구성되어 있다 : OLE Automation (InProcess) Server, 이것은 응용프로그램에게 Visual Basic 와 같은 OLE automation scripting 을 지원하도록 하는 인터페이스이다; Oracle Data Control, VBX (Visual Basic Custom Control) 로서 구현되어 있다; 두개의 C++ Class Library, 하는 Microsoft Foundation Class (MFC) 이고 다른 하나는 Borland International's OWL 을 위한 것이다. Oracle Objects for OLE 는 응용프로그램이 데이테베이스 서버와 통신을 하기 위해서 SQL*Net 을 사용하도록 인터페이스를 제공하는 미들웨어 레이어 이다.

때로는 다양한 클라이언트로 부터 서로 다른 서버에서 동작중인 Oracle, Sybase, SQL Server 그리고 DB2 데이터베이스 등으로 동시에 접속하고자 한다면, 여러개의 드라이버를 사용해야 하는 로딩을 피하면서 할수 있는 방법이 범용적인 데이터베이스 접근 미들웨어 드라이버 (generic database access middleware driver, data access tool 이라고 불린다) 를 이용하는 방법이다. 다종의 데이터베이스 환경에서 ODBC 의 한계를 극복하기 위하여 고안된 미들웨어의 일종인 data access tool 은 서로다른 데이터베이스로 query 를 전달할수 있으며, 이는 ODBC 외에 다른 추가적인 API 를 제공해 준다. 이와 같은 tool 들로는 두가지가 유명한데, 하나는 OpenLink Software 의 Data Access Driver Suit 이고, 다른 하나는 ISG (International Software Group) 의 Navigator 이다.

Computer Associates International 의 Jasmin 과 같은 Object-oriented database 에서는 각각의 database entity 는 그 응용프로그램이 실행시기를 넘어서까지 잔존하는 program object 이다. 다른 말로 하면, Jasmin 을 기반으로 한 컴퓨터 프로그램은 content 를 저장하던지 불러 내고자 할때 SQL 을 사용할 필요없이 데이터베이스 content 를 직접적으로 사용할수 있다. Jasmin archives 는 현재의 ODMG (Object Database Management Group) 의 object model 인 ODMG-93 을 가장 근접하게 따르고 있으며, database 내의 object 와 computer program 내의 object 간의 관계를 제시하고 있다. 결과적으로 프로그램이 database content 를 저장하고, 다루고, 추출하는 동안에 data-type mismatch 를 줄여준다. Mismatch 때문에 프로그램은 추가적으로 데이터베이스 입력사항을 그들 자신의 자료형으로 변환시켜 주어야 한다. (예를 들면 date 형) 이 부가적인 작업이 때로는 프로그래밍의 30-40%를 차지할때도 있다. Computer Associates 의 Jasmin 은 응용프로그램의 크기를 줄이고, 프로그래밍 노력을 줄이지만, 일반적인 데이터베이스 미들웨어 보다는 조금 더 부하가 높다.