데이터베이스 추상화 계층

Database abstraction layer

데이터베이스 추상화 계층(DBAL[1] 또는 DAL)은 SQL Server, DB2, MySQL, Postgre와 같은 데이터베이스와 컴퓨터 애플리케이션 간의 통신을 통합하는 애플리케이션 프로그래밍 인터페이스다.SQL, Oracle 또는 SQLite. 전통적으로 모든 데이터베이스 공급업체는 제품에 맞춘 자체 인터페이스를 제공한다. 애플리케이션에서 지원할 데이터베이스 인터페이스에 대한 코드를 구현하는 것은 애플리케이션 프로그래머의 몫이다. 데이터베이스 추상화 계층은 개발자에게 일관된 API를 제공함으로써 작업량을 줄이고 이 인터페이스 뒤에 있는 데이터베이스 세부사항을 최대한 숨긴다. 수많은 프로그래밍 언어로 서로 다른 인터페이스를 가진 추상화 계층이 많이 존재한다. 애플리케이션이 그러한 계층을 내장하고 있다면, 그것은 데이터베이스 무관이라고 불린다.[2]

데이터베이스 추상화 수준

물리적 수준(가장 낮은 수준)

가장 낮은 레벨은 데이터베이스에 접속하여 사용자가 요구하는 실제 작업을 수행한다. 이 수준에서 개념 지침은 데이터베이스가 이해하는 여러 지침으로 번역되었다. 지침을 올바른 순서로 실행하면 DAL이 개념적 지침을 수행할 수 있다.

물리적 계층의 구현은 데이터베이스별 API를 사용하거나 기본 언어 표준 데이터베이스 액세스 기술과 데이터베이스 버전 SQL을 사용할 수 있다.

데이터 유형 및 운영의 구현은 이 수준에서 가장 특정된 데이터베이스다.

개념적 또는 논리적 수준(중간 또는 다음으로 높은 수준)

개념적 수준은 외부 개념과 지시사항을 물리적 지시로 전환할 수 있는 중간 데이터 구조로 통합한다. 이 층은 외부와 물리적 수준에 걸쳐 있어 가장 복잡하다. 또한 지원되는 모든 데이터베이스와 해당 데이터베이스, API 및 문제를 포괄해야 한다.

이 수준은 데이터베이스 간의 차이를 알고 있으며 모든 경우에 운영의 실행 경로를 구성할 수 있다. 그러나 개념 계층은 각 개별 운영의 실제 구현을 위해 물리적 계층을 방어한다.

외부 또는 뷰 레벨

외부 수준은 사용자와 개발자에게 노출되며 데이터베이스 작업을 수행하기 위한 일관된 패턴을 제공한다. [3] 데이터베이스 작업은 이 수준에서 SQL 또는 심지어 데이터베이스 액세스로만 느슨하게 표현된다.

모든 데이터베이스는 다양한 물리적 데이터 유형과 운영에도 불구하고 뚜렷한 차이 없이 이 수준에서 동등하게 취급되어야 한다.

API의 데이터베이스 추상화

라이브러리는 애플리케이션 개발자에게 낮은 수준의 단일 프로그래밍 인터페이스를 제공하여 데이터베이스에 대한 액세스를 통합한다. 이들의 장점은 특정 질의어(하위 집합)에 얽매이지 않고 목표에 도달하기 위해 얇은 레이어만 구현하면 되기 때문에 가장 흔히 속도와 유연성이다. 모든 SQL 사투리가 서로 유사하기 때문에 애플리케이션 개발자는 모든 언어 기능을 사용할 수 있으며, 일반적으로 사용자 ID와 자격 증명과 같은 데이터베이스 특정 사례에 대해 구성 가능한 요소를 제공할 수 있다. 얇은 레이어는 동일한 질의와 문구를 오버헤드가 거의 없는 다양한 데이터베이스 제품에서 실행할 수 있도록 한다.

데이터베이스 추상화 계층에 널리 사용되는 용도는 API 레벨 추상화 계층과 유사한 객체 지향 프로그래밍 언어에 속한다. C++ 또는 Java와 같은 객체 지향 언어에서, 데이터베이스는 객체를 통해 나타낼 수 있으며, 그 방법 및 구성원(또는 다른 프로그래밍 언어로 동등한 것)은 데이터베이스의 다양한 기능성을 나타낸다. API 수준 인터페이스로 장단점을 공유하기도 한다.

언어 수준 추상화

언어 수준의 데이터베이스 추상화 계층의 예로는 데이터베이스 추상화 계층의 플랫폼 독립 실행인 ODBC가 있을 것이다. 사용자는 ODBC가 데이터베이스 또는 데이터베이스 집합과 통신할 수 있는 특정 드라이버 소프트웨어를 설치한다. 그러면 사용자는 프로그램이 ODBC와 통신하도록 할 수 있으며, 그 다음 사용자 프로그램과 데이터베이스 사이에서 결과를 앞뒤로 중계한다. 이 추상화 수준의 단점은 문장을 대상 데이터베이스가 이해하는 구조로 변환하기 위한 오버헤드 증가다.

또는 OpenDBX나[4] libzDB와 같은 경량 추상화 레이어로 종종 묘사되는 얇은 포장지가 있다.[5] 마지막으로, 대형 프로젝트는 예를 들어 GNOME을 위한 libgda와[6] 같은 자체 라이브러리를 개발할 수 있다.

논쟁들

찬성하여

  • 개발 기간: 소프트웨어 개발자는 응용 프로그램이 지원해야 하는 데이터베이스의 모든 API 대신 데이터베이스 추상화 계층의 API만 알면 된다. 더 많은 데이터베이스가 지원되어야 할수록 시간 절약은 더 크다.
  • 광범위한 잠재적 설치 기반: 데이터베이스 추상화 계층을 사용하는 것은 새로운 설치에 대해 특정 데이터베이스를 사용할 필요가 없다는 것을 의미한다. 즉, 데이터베이스를 전환하기를 꺼리거나 변경할 수 없는 새로운 사용자가 기존 인프라에 배치할 수 있다.
  • 미래 대비: 새로운 데이터베이스 기술이 등장함에 따라 소프트웨어 개발자들은 새로운 인터페이스에 적응할 필요가 없을 것이다.
  • 개발자 테스트: 프로덕션 데이터베이스를 개발자 레벨 유닛 테스트를 위한 데이터의 데스크톱 레벨 구현으로 대체할 수 있다.
  • 추가된 데이터베이스 특징: 데이터베이스와 DAL에 따라, DAL이 데이터베이스에 기능을 추가하는 것이 가능할 수 있다. DAL은 표준이지만 지원되지 않는 기능 또는 완전히 새로운 기능을 만들기 위해 데이터베이스 프로그래밍 시설 또는 기타 방법을 사용할 수 있다. 예를 들어 DBvolution DAL은 이를 지원하지 않는 여러 데이터베이스에 대해 표준 편차 기능을 구현한다.

그것에 대항하여

  • 속도: 모든 추상화 계층은 실행해야 하는 추가 코드의 양에 따라 전체 속도를 다소 감소시킬 것이다. 데이터베이스 계층이 기본 데이터베이스 인터페이스에서 더 많이 추상화되고 모든 데이터베이스 백엔드에 없는 기능을 에뮬레이트하려고 할수록 전체 성능이 느려진다. ODBC와 마찬가지로 쿼리 언어를 통합하려는 데이터베이스 추상화 계층의 경우 특히 그렇다.
  • 종속성: 데이터베이스 추상화 계층은 소프트웨어 시스템에 또 다른 기능적 종속성을 제공한다. 즉, 주어진 데이터베이스 추상화 계층은 다른 어떤 것과 마찬가지로 결국 구식, 구식 또는 지원되지 않을 수 있다.
  • 마스킹된 작업: 데이터베이스 추상화 계층은 사용 가능한 데이터베이스 작업 수를 지원되는 데이터베이스 백업에서 지원되는 작업의 하위 집합으로 제한할 수 있다. 특히 데이터베이스 추상화 계층은 데이터베이스 백엔드별 최적화 또는 디버깅 기능을 완전히 지원하지 않을 수 있다. 이러한 문제는 데이터베이스 크기, 규모 및 복잡성에 따라 크게 확대된다.

참고 항목

참조

  1. ^ Ambler, Tim; Cloud, Nicholas (2015). JavaScript Frameworks for Modern Web Dev. Apress. p. 346. ISBN 978-1-4842-0662-1.
  2. ^ http://searchdatamanagement.techtarget.com/definition/database-agnostic
  3. ^ "Levels of Abstraction".
  4. ^ "OpenDBX". linuxnetworks.de. 24 June 2012. Retrieved 26 July 2018.
  5. ^ "Libzdb". tildeslash.com. 2018. Retrieved 26 July 2018.
  6. ^ "GNOME-DB". 12 June 2015. Retrieved 26 July 2018. Libgda library [...] is mainly a database and data abstraction layer, and includes a GTK+ based UI extension, and some graphical tools.