ODBC

ODBC(Open DataBase Connectivity)는 데이터베이스 관리 시스템(DBMS)에 접근하기 위한 C 언어 표준 애플리케이션 프로그래밍 인터페이스(API)이다. ODBC 설계자들은 이것이 데이터베이스 시스템 및 운영체제에 독립적이도록 만드는 것을 목표로 했다. ODBC를 사용하여 작성된 응용 프로그램은 데이터 액세스 코드의 변경 없이 클라이언트와 서버 측 모두에서 다른 플랫폼으로 이식될 수 있다.

ODBC는 응용 프로그램과 DBMS 사이의 번역 계층으로 ODBC 드라이버를 사용하여 DBMS 독립성을 달성한다. 응용 프로그램은 자신이 연결된 ODBC 드라이버 관리자를 통해 ODBC 함수를 사용하고, 드라이버는 질의를 DBMS로 전달한다. ODBC 드라이버는 프린터 드라이버나 다른 드라이버와 유사한 것으로 생각할 수 있으며, 응용 프로그램이 사용할 표준 함수 세트를 제공하고 DBMS 전용 기능을 구현한다. ODBC를 사용할 수 있는 응용 프로그램을 "ODBC 호환"이라고 한다. 모든 ODBC 호환 응용 프로그램은 드라이버가 설치된 모든 DBMS에 접근할 수 있다. 드라이버는 모든 주요 DBMS, 주소록 시스템 및 마이크로소프트 엑셀과 같은 많은 다른 데이터 소스, 그리고 심지어 텍스트나 CSV 파일용으로도 존재한다.

ODBC는 원래 1990년대 초 마이크로소프트와 심바 테크놀로지스에 의해 개발되었으며, 유닉스 및 메인프레임 분야에서 SQL 액세스 그룹에 의해 표준화된 호출 수준 인터페이스(CLI)의 기초가 되었다. ODBC는 CLI 표준화 과정에서 제거된 여러 기능을 유지했다. 나중에 전체 ODBC가 다시 해당 플랫폼으로 이식되었으며, CLI보다 훨씬 더 잘 알려진 사실상 표준이 되었다. CLI는 여전히 ODBC와 유사하며, 응용 프로그램은 적은 변경만으로 한 플랫폼에서 다른 플랫폼으로 이식될 수 있다.

역사

ODBC 이전

1970년대 메인프레임 기반 관계형 데이터베이스의 도입으로 데이터 접근 방식이 난립하게 되었다. 일반적으로 이러한 시스템은 사용자가 영어와 유사한 명령어를 입력하고 출력을 받을 수 있는 간단한 명령 프로세서와 함께 작동했다. 가장 잘 알려진 예로는 IBM의 SQL과 인그레스 프로젝트의 QUEL이 있다. 이러한 시스템은 다른 응용 프로그램이 데이터에 직접 접근하는 것을 허용할 수도 있고 허용하지 않을 수도 있었으며, 허용하는 경우에도 매우 다양한 방법론을 사용했다. SQL의 도입은 언어 표준화 문제를 해결하는 것을 목표로 했으나, 구현상의 실질적인 차이는 여전히 남아 있었다.

SQL 언어는 기초적인 프로그래밍 기능만 갖추고 있었기 때문에, 사용자들은 종종 포트란이나 C와 같은 다른 언어로 작성된 프로그램 내에서 SQL을 사용하고 싶어 했다. 이는 임베디드 SQL이라는 개념으로 이어졌으며, 이를 통해 SQL 코드를 다른 언어 내에 삽입할 수 있게 되었다. 예를 들어, SELECT * FROM city와 같은 SQL 문을 C 소스 코드 내에 텍스트로 삽입할 수 있었고, 컴파일 과정에서 해당 문을 SQL 시스템으로 전달하는 라이브러리 내의 함수를 직접 호출하는 맞춤형 형식으로 변환되었다. 명령문에서 반환된 결과는 유사한 라이브러리 코드를 사용하여 char*나 char[]와 같은 C 데이터 형식으로 다시 해석되었다.

임베디드 SQL 방식에는 몇 가지 문제가 있었다. 다양한 종류의 SQL과 마찬가지로, 이를 사용하는 임베디드 SQL도 플랫폼마다 다를 뿐만 아니라 한 플랫폼 내의 언어 간에도 크게 달랐다. 예를 들어 IBM DB2를 호출하는 시스템은 자체 IBM SQL/DS를 호출하는 시스템과 매우 다르게 보였다. 임베디드 SQL 개념의 또 다른 주요 문제는 SQL 코드가 프로그램의 소스 코드에서만 변경될 수 있다는 점이었고, 따라서 질의의 작은 변경조차도 수정하기 위해 상당한 프로그래머의 노력이 필요했다. SQL 시장에서는 이를 정적 SQL이라고 불렀으며, 거의 모든 SQL 시스템과 함께 제공되는 명령줄 인터페이스나 호출될 때까지 SQL을 일반 텍스트로 남겨두는 프로그래밍 인터페이스처럼 언제든지 변경할 수 있는 동적 SQL과 대조되었다. 동적 SQL 시스템은 1980년대 SQL 벤더들의 주요 관심사가 되었다.

오래된 메인프레임 데이터베이스와 이를 기반으로 한 최신 마이크로컴퓨터 기반 시스템은 대개 사용자와 데이터베이스 엔진 사이에 SQL과 같은 명령 프로세서가 없었다. 대신 데이터는 프로그램에 의해 직접 접근되었다. 대형 메인프레임 시스템의 경우 프로그래밍 라이브러리에 의해, DBASE 및 유사한 응용 프로그램의 경우 명령줄 인터페이스나 대화형 폼 시스템에 의해 접근되었다. dBASE의 데이터는 일반적으로 해당 컴퓨터에서 실행되는 다른 프로그램에 의해 직접 접근될 수 없었다. 해당 프로그램들에게 종종 라이브러리를 통해 이 데이터에 접근하는 방법이 제공되었을 수도 있지만, 이는 다른 데이터베이스 엔진이나 심지어 동일한 엔진의 다른 데이터베이스와도 작동하지 않았다. 사실상 이러한 모든 시스템은 정적이었으며, 이는 상당한 문제를 야기했다.

초기 노력

1980년대 중반까지 마이크로컴퓨터의 급격한 성능 향상, 특히 그래픽 사용자 인터페이스의 도입과 로터스 1-2-3와 같은 데이터가 풍부한 응용 프로그램의 등장은 클라이언트 서버 모델 컴퓨팅에서 개인용 컴퓨터를 클라이언트 측 플랫폼으로 선택하는 것에 대한 관심을 고조시켰다. 이 모델에서 대형 메인프레임과 미니컴퓨터는 주로 근거리 통신망을 통해 마이크로컴퓨터에 데이터를 제공하는 데 사용되었고, 마이크로컴퓨터는 해당 데이터를 해석, 표시 및 조작했다. 이 모델이 작동하려면 데이터 접근 표준이 필수적이었다. 메인프레임 분야에서는 한 매장의 모든 컴퓨터가 한 벤더의 제품이고 클라이언트는 그들과 직접 통신하는 단말기일 가능성이 높았지만, 마이크로 분야에서는 그러한 표준화가 없었으며 어떤 클라이언트라도 어떤 네트워킹 시스템을 사용하여 어떤 서버에든 접근할 수 있었다.

1980년대 후반까지 이 목적을 위한 추상화 계층을 제공하려는 여러 노력이 진행되었다. 이들 중 일부는 메인프레임과 관련되어 있었으며, 해당 기계에서 실행되는 프로그램이 다양한 SQL 간의 번역을 수행하고 다른 메인프레임이나 마이크로컴퓨터 프로그램이 호출할 수 있는 단일 공통 인터페이스를 제공하도록 설계되었다. 이러한 솔루션에는 IBM의 DRDA(Distributed Relational Database Architecture)와 애플 컴퓨터의 데이터 액세스 언어(Data Access Language)가 포함되었다. 그러나 필요한 네트워킹 또는 파일 번역 지원을 포함한 완전한 프로토콜 스택을 포함하여 전적으로 마이크로컴퓨터에서 실행되는 시스템이 훨씬 더 흔했다.

그러한 시스템의 초기 예 중 하나는 로터스 디벨롭먼트의 데이터렌즈(DataLens)였으며, 초기에는 블루프린트(Blueprint)로 알려졌다. 1-2-3용으로 개발된 블루프린트는 SQL/DS, DB2, FOCUS 및 다양한 유사 메인프레임 시스템뿐만 아니라 dBASE 및 나중에 마이크로소프트 SQL 서버로 발전하게 되는 초기 마이크로소프트/애슈턴 테이트(Ashton-Tate)의 노력을 포함한 마이크로컴퓨터 시스템을 지원했다.^[1] 나중의 ODBC와 달리 블루프린트는 SQL과 유사한 명령 언어가 없는 순수 코드 기반 시스템이었다. 대신 프로그래머는 자료 구조를 사용하여 질의 정보를 저장하고, 이러한 많은 구조를 서로 연결하여 질의를 구성했다. 로터스는 이러한 복합 구조를 질의 트리(query trees)라고 불렀다.^[2]

비슷한 시기에 사이베이스(톰 해긴), 탠덤 컴퓨터(짐 그레이 & 라오 엔들루리) 및 마이크로소프트(카일 가이거)의 멤버들을 포함한 산업 팀이 표준화된 동적 SQL 개념을 연구하고 있었다. 시스템의 상당 부분은 사이베이스의 DB-Library 시스템을 기반으로 했으며, 사이베이스 전용 섹션은 제거되고 다른 플랫폼을 지원하기 위한 여러 추가 사항이 포함되었다.^[3] DB-Library는 특정 언어에 밀접하게 연결된 라이브러리 시스템에서 운영체제가 제공하고 해당 플랫폼의 언어가 표준을 준수하도록 요구하는 라이브러리 시스템으로 옮겨가는 산업 전반의 움직임 덕분에 탄생할 수 있었다. 이는 단일 라이브러리가 주어진 플랫폼의 (잠재적으로) 모든 프로그래밍 언어에서 사용될 수 있음을 의미했다.

마이크로소프트 데이터 액세스 API의 첫 번째 초안은 로터스의 블루프린트 발표와 거의 같은 시기인 1989년 4월에 발표되었다.^[4] 블루프린트가 크게 앞서 있었음에도 불구하고(MSDA가 아직 종이 프로젝트였을 때 이미 실행 중이었다), SQL이 사실상의 데이터베이스 표준이 될 것이 분명해지자 로터스는 결국 MSDA 노력에 합류했다.^[2] 상당한 업계의 의견 수렴을 거쳐 1989년 여름에 이 표준은 SQL 연결성(SQL Connectivity, SQLC)이 되었다.^[5]

SAG와 CLI

1988년 주로 유닉스 및 데이터베이스 커뮤니티의 여러 벤더가 SQL 언어에 대한 단일 기본 표준을 만들기 위해 SQL 액세스 그룹(SAG)을 결성했다. 첫 번째 회의에서 이 노력이 SQL 언어 자체에만 집중해야 하는지, 아니면 그들이 호출 수준 인터페이스(CLI)라고 부르는 동적 SQL 언어 임베딩 시스템을 포함한 더 넓은 표준화를 시도해야 하는지에 대해 상당한 논쟁이 있었다.^[6] 당시 여전히 MS 데이터 액세스로 알려졌던 초기 초안을 가지고 회의에 참석한 마이크로소프트의 카일 가이거는 디지털 이큅먼트 코퍼레이션(DEC)의 제프 발보니와 래리 반스를 SQLC 회의에 초대했다. SQLC는 DEC가 주도하고 있던 CLI 요구에 대한 잠재적인 해결책이었다.

마이크로소프트, 탠덤, DEC, 사이베이스로 구성된 새로운 SQLC "4인방"은 1990년 6월 다음 SAG 회의에 업데이트된 SQLC 버전을 가져왔다.^[7] SAG는 모든 경쟁 디자인에 표준 노력을 개방함으로써 대응했으나, 많은 제안 중 오라클만이 심각한 경쟁이 되는 시스템을 가지고 있었다. 결국 SQLC가 투표에서 승리하여 표준 초안이 되었으나, API의 많은 부분이 제거된 후에야 가능했다. 이 기간 동안 표준 문서는 120페이지에서 50페이지로 축소되었다. 또한 이 시기에 호출 수준 인터페이스라는 명칭이 공식적으로 채택되었다.^[7] 1995년 SQL/CLI는 국제 SQL 표준인 ISO/IEC 9075-3의 일부가 되었다.^[8] SAG 자체는 1996년 X/Open 그룹에 인수되었으며, 시간이 지나면서 오픈 그룹의 공통 응용 환경(Common Application Environment)의 일부가 되었다.

마이크로소프트는 CLI 버전에서 제거된 많은 고급 기능을 유지하면서 원래의 SQLC 표준 작업을 계속했다. 여기에는 스크롤 가능한 커서 및 메타데이터 정보 질의와 같은 기능이 포함되었다. API의 명령들은 그룹으로 나뉘었다. 코어(Core) 그룹은 CLI와 동일했고, 레벨 1 확장(Level 1 extensions)은 드라이버에서 구현하기 쉬운 명령들이었으며, 레벨 2 명령들은 커서와 같은 더 고급 기능을 포함했다. 제안된 표준은 1991년 12월에 발표되었으며, 1992년 내내 업계 의견을 수렴하여 시스템에 반영한 결과 또 다른 이름 변경을 거쳐 ODBC가 되었다.^[9]

JET와 ODBC

이 시기에 마이크로소프트는 Jet 데이터베이스 시스템을 개발하는 중이었다. Jet는 세 가지 주요 하위 시스템을 결합했다. ISAM 기반 데이터베이스 엔진(혼동스럽게도 이름이 역시 Jet이다), 응용 프로그램이 해당 데이터에 접근할 수 있게 해주는 C 기반 인터페이스, 그리고 동일한 C 인터페이스가 입출력을 패러독스 및 xBase와 같은 다른 ISAM 기반 데이터베이스로 리디렉션할 수 있게 해주는 드라이버 동적 링크 라이브러리(DLL) 모음이다. Jet는 당시 데이터렌즈(DataLens)로 이름이 바뀐 블루프린트와 유사한 방식으로 공통 마이크로컴퓨터 데이터베이스에 접근하기 위해 한 세트의 호출을 사용할 수 있게 해주었다. 그러나 Jet는 SQL을 사용하지 않았다. 데이터렌즈와 마찬가지로 인터페이스는 C 언어였으며 자료 구조와 함수 호출로 구성되었다.

SAG 표준화 노력은 마이크로소프트가 그들의 Jet 시스템을 새로운 CLI 표준에 맞출 기회를 제공했다. 이는 윈도우를 CLI 개발의 주요 플랫폼으로 만들 뿐만 아니라, 사용자가 SQL을 사용하여 Jet와 다른 데이터베이스 모두에 접근할 수 있게 해줄 것이었다. 누락된 것은 해당 호출을 텍스트 형식에서 Jet에서 사용되는 C 인터페이스로 변환할 수 있는 SQL 파서였다. 이를 해결하기 위해 마이크로소프트는 페이지어헤드 소프트웨어와 파트너십을 맺어 그들의 기존 질의 프로세서인 SIMBA를 사용했다. SIMBA는 Jet의 C 라이브러리 위에서 파서로 사용되어 Jet를 SQL 데이터베이스로 변화시켰다. 그리고 Jet는 해당 C 기반 호출을 다른 데이터베이스로 전달할 수 있었기 때문에, 이는 SIMBA가 다른 시스템을 질의하는 것도 가능하게 했다. 마이크로소프트는 엑셀 스프레드시트 문서를 SQL로 접근 가능한 데이터베이스 테이블로 바꾸기 위해 엑셀용 드라이버를 포함했다.^[10]

출시 및 지속적인 개발

ODBC 1.0은 1992년 9월에 출시되었다.^[11] 당시에는 (ISAM에 비해) SQL 데이터베이스에 대한 직접적인 지원이 거의 없었으며, 초기 드라이버는 성능이 좋지 않은 것으로 유명했다. 이 중 일부는 호출이 Jet 기반 스택을 통과하는 경로 때문에 피할 수 없는 문제였다. SQL 데이터베이스에 대한 ODBC 호출은 먼저 심바 테크놀로지스의 SQL 방언에서 Jet의 내부 C 기반 형식으로 변환된 다음, 데이터베이스를 위한 SQL 호출로 다시 변환하기 위해 드라이버로 전달되었다. 디지털 이큅먼트와 오라클은 모두 자신들의 데이터베이스용 드라이버를 개발하기 위해 심바 테크놀로지스와 계약했다.^[12]

1993년경 오픈링크 소프트웨어(OpenLink Software)는 PROGRESS DBMS를 위한 최초의 독립 개발된 제3자 ODBC 드라이버 중 하나를 출시했으며,^[13] 곧이어 유닉스 계열 운영체제(AIX, HP-UX, 솔라리스, 리눅스 등), VMS, 윈도우 NT, OS/2 및 기타 운영체제에서 사용하기 위해 PROGRESS, 사이베이스, 오라클 및 기타 DBMS용 UDBC(ODBC 및 SAG/CLI와 동등한 크로스 플랫폼 API) SDK 및 관련 드라이버를 출시했다.^[14]

한편 CLI 표준화 작업은 지지부진하게 이어졌고, 1995년 3월에야 최종 버전이 확정되었다. 그때쯤 마이크로소프트는 이미 비지제닉 소프트웨어(Visigenic Software)에 비-윈도우 플랫폼에서 ODBC를 개발할 수 있는 소스 코드 라이선스를 부여한 상태였다. 비지제닉은 ODBC를 클래식 맥 OS와 다양한 유닉스 플랫폼으로 이식했으며, 그곳에서 ODBC는 빠르게 사실상의 표준이 되었다.^[15] "진정한" CLI는 오늘날 드물다. 두 시스템은 여전히 유사하며, 많은 응용 프로그램이 거의 또는 전혀 변경 없이 ODBC에서 CLI로 이식될 수 있다.^[16]

시간이 지나면서 데이터베이스 벤더들은 드라이버 인터페이스를 넘겨받아 자신들의 제품에 대한 직접적인 링크를 제공했다. Jet나 유사한 래퍼를 통한 중간 변환을 생략함으로써 종종 더 높은 성능을 얻을 수 있었다. 그러나 그때쯤 마이크로소프트는 주소록에서 텍스트 파일에 이르기까지 더 넓은 범위의 데이터 소스에 직접 접근할 수 있게 해주는 OLE DB^[17] 개념(최근 다시 복구됨 ^[18])으로 관심을 돌렸다. 액티브엑스 데이터 오브젝트(ADO) 및 ADO.NET을 포함하여 ODBC로부터 관심을 더욱 멀어지게 하는 여러 새로운 시스템이 뒤따랐으며, 이들은 시간이 지나면서 ODBC와 어느 정도 상호작용했다.

마이크로소프트가 ODBC를 직접 다루는 일에서 멀어지자, 유닉스 분야에서는 점점 더 이를 수용했다. 이는 시장 내의 두 가지 변화에 의해 추진되었는데, 하나는 이러한 소스에 텍스트가 아닌 형식으로 접근할 필요를 제공한 그놈(GNOME)과 같은 그래픽 사용자 인터페이스(GUI)의 도입이었고, 다른 하나는 초기 유닉스 하에서 PostgreSQL 및 MySQL과 같은 오픈 소프트웨어 데이터베이스 시스템의 출현이었다. 나중에 애플이 맥 OS X 10.2(Jaguar)에서 표준 유닉스 측 iODBC 패키지를 사용하기 위해 ODBC를 채택한 것은(오픈링크 소프트웨어가 2001년부터 맥 OS X 10.0 및 맥 OS 9용으로 독립적으로 제공해 오던 것 ^[19]) ODBC를 크로스 플랫폼 데이터 접근을 위한 표준으로 더욱 확고히 했다.

썬 마이크로시스템즈는 ODBC 시스템을 자신들의 오픈 표준인 JDBC의 기초로 사용했다. 대부분의 면에서 JDBC는 C 대신 자바 프로그래밍 언어를 위한 ODBC 버전으로 간주될 수 있다. JDBC-to-ODBC 브리지는 자바 기반 프로그램이 기본 JDBC 드라이버가 없는 플랫폼에서 ODBC 드라이버를 통해 데이터 소스에 접근할 수 있게 해주지만, 현재는 상대적으로 드물다. 반대로 ODBC-to-JDBC 브리지는 C 기반 프로그램이 적절한 ODBC 드라이버가 없는 플랫폼이나 데이터베이스에서 JDBC 드라이버를 통해 데이터 소스에 접근할 수 있게 해준다.

오늘날의 ODBC

ODBC는 오늘날에도 널리 사용되고 있으며, 대부분의 플랫폼과 데이터베이스에서 드라이버를 사용할 수 있다. 기존 도구들이 테스트 및 디버깅을 위해 이러한 엔진의 프런트엔드 역할을 할 수 있도록 SQLite와 같이 내장형으로 제작된 데이터베이스 엔진용 ODBC 드라이버를 찾는 것도 어렵지 않다.^[20]

최근 몇 년 동안 ODBC는 Salesforce, Google BigQuery, Snowflake와 같은 클라우드 기반 데이터 소스 및 SaaS 플랫폼에 연결하기 위해서도 채택되었다. (윈도우, macOS, 리눅스용) 크로스 플랫폼 드라이버 가용성 덕분에 Power BI, Tableau, RStudio와 같은 현대적인 분석 및 비즈니스 인텔리전스 도구와 통합이 가능해졌다. 이는 ODBC의 관련성을 전통적인 관계형 데이터베이스를 넘어 클라우드 데이터 웨어하우징 및 데이터 과학 워크플로까지 확장시켰다.

버전 역사

ODBC 사양

출처:^[21]

• 1.0: 1992년 9월 출시^[22]
• 2.0: 1994년경
• 2.5
• 3.0: 1995년경, Intersolv의 존 굿슨과 IBM의 프랭크 펠로우 및 폴 코튼이 ODBC 3.0에 중요한 기여를 함^[23]
• 3.5: 1997년경
• 3.8: 2009년경, 윈도우 7과 함께 제공^[24]
• 4.0: 2016년 6월 개발 발표^[25], 2017년 9월 출시된 SQL Server 2017에서 첫 구현, 2018년 말 추가 데스크톱 드라이버 출시 Github 최종 사양

데스크톱 데이터베이스 드라이버

출처:^[26]

• 1.0 (1993–08): 페이지어헤드 소프트웨어에서 제작한 SIMBA 질의 프로세서를 사용했다.
• 2.0 (1994–12): ODBC 2.0과 함께 사용되었다.
• 3.0 (1995–10): 윈도우 95 및 윈도우 NT 워크스테이션 또는 NT 서버 3.51을 지원한다. 이 릴리스에는 32비트 드라이버만 포함되었다.
• 3.5 (1996–10): 더블 바이트 문자 세트(DBCS)를 지원하고 파일 데이터 소스 이름(DSN) 사용을 수용했다. 마이크로소프트 액세스 드라이버는 윈도우 95/98 및 윈도우 NT 3.51 이상 운영체제의 알파 플랫폼에서 사용하기 위한 RISC 버전으로 출시되었다.
• 4.0 (1998년 말): 마이크로소프트 Jet 엔진 유니코드 형식을 지원하고 이전 버전의 ANSI 형식과의 호환성을 제공한다.

드라이버 및 관리자

드라이버

ODBC는 장치 드라이버 모델을 기반으로 하며, 여기서 드라이버는 표준 명령 및 함수 세트를 기본 시스템에서 요구하는 특정 호출로 변환하는 데 필요한 로직을 캡슐화한다. 예를 들어 프린터 드라이버는 인쇄 시스템을 사용하는 응용 프로그램에 인쇄 명령의 표준 세트인 API를 제공한다. 해당 API에 대한 호출은 드라이버에 의해 실제 하드웨어에서 사용되는 형식(예: 포스트스크립트 또는 PCL)으로 변환된다.

ODBC의 경우, 드라이버는 여러 광범위한 범주로 나눌 수 있는 많은 함수를 캡슐화한다. 한 세트의 함수는 주로 드라이버가 통신하는 DBMS를 찾고, 연결하고, 연결을 해제하는 것과 관련이 있다. 두 번째 세트는 ODBC 시스템에서 DBMS로 SQL 명령을 보내는 데 사용되며, 내부적으로 지원되지 않는 명령을 변환하거나 해석한다. 예를 들어 커서를 지원하지 않는 DBMS는 드라이버에서 이 기능을 에뮬레이션할 수 있다. 마지막으로, 주로 내부적으로 사용되는 또 다른 명령 세트는 DBMS의 내부 형식의 데이터를 C 언어 형식을 기반으로 하는 표준화된 ODBC 형식 세트로 변환하는 데 사용된다.

ODBC 드라이버는 ODBC 호환 응용 프로그램이 데이터 소스(보통 DBMS)를 사용할 수 있게 한다. 드라이버 자체 내부에 소형 DBMS를 구현함으로써 CSV 파일과 같은 데이터 소스를 위한 일부 비-DBMS 드라이버도 존재한다. ODBC 드라이버는 오라클, PostgreSQL, MySQL, 마이크로소프트 SQL 서버(단, Compact/CE 에디션 제외), Mimer SQL, 사이베이스 ASE, SAP HANA^[27][28] 및 IBM DB2를 포함한 대부분의 DBMS용으로 존재한다. 기술마다 기능이 다르기 때문에 대부분의 ODBC 드라이버는 ODBC 표준에 정의된 모든 기능을 구현하지는 않는다. 일부 드라이버는 표준에 정의되지 않은 추가 기능을 제공한다.

드라이버 관리자

장치 드라이버는 일반적으로 별도의 관리자(Manager) 계층에 의해 열거, 설정 및 관리되며, 관리자는 추가 기능을 제공할 수 있다. 예를 들어 인쇄 시스템은 종종 드라이버 위에 스풀링 기능을 제공하여 지원되는 모든 프린터에 대해 인쇄 스풀링을 제공하는 기능을 포함한다.

ODBC에서는 드라이버 관리자(DM)가 이러한 기능을 제공한다.^[29] DM은 설치된 드라이버를 열거하고 이를 종종 GUI 기반의 목록으로 제시할 수 있다.

그러나 ODBC 시스템의 운영에 더 중요한 것은 DM의 데이터 소스 이름(DSN) 개념이다. DSN은 DBMS 자체와 대조적으로 특정 데이터 소스에 연결하는 데 필요한 추가 정보를 수집한다. 예를 들어 동일한 MySQL 드라이버를 사용하여 모든 MySQL 서버에 연결할 수 있지만, 로컬 개인 서버에 연결하기 위한 연결 정보는 인터넷에 호스팅된 공개 서버에 연결하는 데 필요한 정보와 다르다. DSN은 이 정보를 표준화된 형식으로 저장하고, DM은 연결 요청 중에 드라이버에 이를 제공한다. DM은 또한 사람이 읽을 수 있는 이름을 사용하여 DSN 목록을 제시하고 실행 시 다른 리소스에 연결하기 위해 이를 선택하는 기능을 포함한다.

DM은 또한 부분적으로 완성된 DSN을 저장하는 기능과 실행 시 누락된 정보를 사용자에게 요청하는 코드 및 로직을 포함한다. 예를 들어 필수 비밀번호 없이 DSN을 생성할 수 있다. ODBC 응용 프로그램이 이 DSN을 사용하여 DBMS에 연결하려고 하면 시스템은 일시 중지하고 사용자에게 비밀번호를 제공하도록 요청한 후 계속 진행한다. 이는 응용 프로그램 개발자가 이러한 종류의 코드를 생성해야 하는 부담뿐만 아니라 어떤 질문을 해야 하는지 알아야 하는 부담을 덜어준다. 이 모든 것은 드라이버와 DSN에 포함되어 있다.

브리징 구성

브리지는 특별한 종류의 드라이버로, 다른 드라이버 기반 기술을 사용하는 드라이버이다.

ODBC-to-JDBC (ODBC-JDBC) 브리지

ODBC-JDBC 브리지는 데이터베이스에 연결하기 위해 JDBC 타입 1 드라이버의 서비스를 사용하는 ODBC 드라이버로 구성된다. 이 드라이버는 ODBC 함수 호출을 JDBC 메서드 호출로 번역한다. 프로그래머는 대개 특정 데이터베이스용 ODBC 드라이버는 없지만 JDBC 드라이버를 사용할 수 있을 때 이러한 브리지를 사용한다. 예: OpenLink ODBC-JDBC Bridge, SequeLink ODBC-JDBC Bridge.

JDBC-to-ODBC (JDBC-ODBC) 브리지

JDBC-ODBC 브리지는 대상 데이터베이스에 연결하기 위해 ODBC 드라이버를 고용하는 JDBC 드라이버로 구성된다. 이 드라이버는 JDBC 메서드 호출을 ODBC 함수 호출로 번역한다. 프로그래머는 대개 주어진 데이터베이스에 JDBC 드라이버는 없지만 ODBC 드라이버를 통해 접근할 수 있을 때 이러한 브리지를 사용한다. 썬 마이크로시스템즈는 JVM에 이러한 브리지를 하나 포함시켰으나, JDBC 드라이버가 거의 없던 시절의 임시방편으로 간주했다. (내장된 JDBC-ODBC 브리지는 자바 8에서 JVM으로부터 제거되었다 ^[30]). 썬은 이 브리지를 운영 환경용으로 의도하지 않았으며 일반적으로 사용을 권장하지 않았다. 2008년 현재 독립적인 데이터 액세스 벤더들이 두 메커니즘의 현재 표준을 지원하며 JVM 내장 브리지보다 성능이 훨씬 뛰어난 JDBC-ODBC 브리지를 제공하고 있다. 예: OpenLink JDBC-ODBC Bridge, SequeLink JDBC-ODBC Bridge, ZappySys JDBC-ODBC Bridge.

OLE DB-to-ODBC 브리지

OLE DB-ODBC 브리지는 대상 데이터베이스에 연결하기 위해 ODBC 드라이버의 서비스를 사용하는 OLE DB 제공자(Provider)로 구성된다. 이 제공자는 OLE DB 메서드 호출을 ODBC 함수 호출로 번역한다. 프로그래머는 대개 주어진 데이터베이스에 OLE DB 제공자는 없지만 ODBC 드라이버를 통해 접근할 수 있을 때 이러한 브리지를 사용한다. 마이크로소프트는 COM 인식 언어(예: 비주얼 베이직)에서의 개발을 단순화하기 위해 다른 데이터베이스 드라이버와 함께 MDAC 시스템 구성 요소 번들의 일부로 MSDASQL.DLL을 제공한다. 제3자 업체들도 이를 개발했으며, 특히 마이크로소프트가 처음에 그들의 64비트 OS에서 이 브리지를 더 이상 사용하지 않기로 했을 때 오픈링크 소프트웨어의 ODBC 데이터 소스용 64비트 OLE DB 제공자가 그 공백을 메웠다.^[31] (나중에 마이크로소프트는 마음을 바꾸었으며, 윈도우 서버 2008 및 윈도우 비스타 SP1부터 64비트 윈도우에는 MSDASQL의 64비트 버전이 포함되어 출시되었다.) 예: OpenLink OLEDB-ODBC Bridge 보관됨 2017-03-27 - 웨이백 머신, SequeLink OLEDB-ODBC Bridge.

ADO.NET-to-ODBC 브리지

ADO.NET-ODBC 브리지는 대상 데이터베이스에 연결하기 위해 ODBC 드라이버의 서비스를 사용하는 ADO.NET 제공자로 구성된다. 이 제공자는 ADO.NET 메서드 호출을 ODBC 함수 호출로 번역한다. 프로그래머는 대개 주어진 데이터베이스에 ADO.NET 제공자는 없지만 ODBC 드라이버를 통해 접근할 수 있을 때 이러한 브리지를 사용한다. 마이크로소프트는 C#에서의 개발을 단순화하기 위해 다른 데이터베이스 드라이버와 함께 MDAC 시스템 구성 요소 번들의 일부로 이를 제공한다. 제3자 업체들도 이를 개발했다. 예: OpenLink ADO.NET-ODBC Bridge, SequeLink ADO.NET-ODBC Bridge.

같이 보기

• GNOME-DB
• ADO.NET