네비게이션 데이터베이스

Navigational database

네비게이션 데이터베이스는 주로 다른 오브젝트의 참조에 따라 레코드나 오브젝트를 찾는 데이터베이스 유형이다. 이 용어는 찰스 바흐만의 1973년 튜링상 논문인 '프로그래머 as Navigator'라는 제목으로 대중화되었다.[1] 이 논문은 새로운 디스크 기반 데이터베이스 시스템이 프로그래머가 기록에서 기록까지의 관계에 따라 임의의 항법 경로를 선택할 수 있도록 했다는 사실을 강조하면서, 데이터 액세스가 엄격히 순차적으로 이루어지는 이전의 자기테이프 및 펀치 카드 시스템의 제약과 대조된다.

초기 항법 데이터베이스 중 하나는 1960년대 제너럴 일렉트릭(General Electric)을 위해 바흐만이 개발한 통합 데이터 저장소(IDS)이다. IDS는 1969년에 CODASYL 데이터베이스 모델의 기반이 되었다.

바흐만이 내비게이션의 개념을 추상적인 용어로 기술했지만, 항법 접근에 대한 생각은 CODASYL 데이터 조작 언어의 절차적 설계와 강하게 연관되게 되었다. 예를 들어 1982년에 쓴 《치히리치스》와 《로코프스키[2]》에는 '통화의 개념은 항해 개념의 중심'이라고 명시되어 있다. 통화의 개념에 의해, 그들은 프로그램이 처리하고 있는 기록의 모든 순서에서 현재의 위치를 유지(명확히 또는 암묵적으로)하고, 다음과 같은 작업을 하는 것을 말한다. GET NEXT 그리고 GET PRIOR 현재 위치를 검색하는 동시에 현재 위치를 검색되는 레코드로 변경한다.

따라서 항법 데이터베이스 프로그래밍은 본질적으로 절차적인 것으로 간주되었고, 더욱이 현재 상태를 유지하는 암묵적인 글로벌 변수 집합(통화 지표)의 유지에 의존하게 되었다. 이와 같이, 그 접근방식은 관계형 모델이 사용하는 선언적 프로그래밍 스타일과 정반대되는 것으로 보였다. SQL과 같은 관계 언어의 선언적 특성은 더 나은 프로그래머 생산성과 더 높은 수준의 데이터 독립성(데이터베이스 구조가 진화함에 따라 프로그램이 계속 작동할 수 있는 능력)을 제공했다. 그 결과, 항법 인터페이스는 선언적 질의 언어에 의해 1980년대에 점차 삭제되었다.

1990년대에 복잡한 데이터(예: 공간 데이터베이스 및 엔지니어링 데이터베이스)를 처리하는 특정 애플리케이션의 경우 관계 미적분학에는 한계가 있다는 것이 분명해지기 시작했다. 당시, 여러 회사가 NoSQL이라는 마케팅 용어를 사용하여 새로운 시스템을 설명하는 등, 전체 데이터베이스 시장의 재평가가 시작되었다. 이러한 시스템 중 다수는 CODASYL DML과 통화 지표는 멀리 떨어져 있지만 바흐만의 "비교적" 비전을 구현하는 것으로 이해할 수 있는 데이터 조작 언어를 도입했다. 이러한 언어들 중 일부는 절차적이다; 다른 언어들(예: XPath)은 완전히 선언적이다. 그래프 데이터베이스와 같은 탐색 개념의 오프슈트는 현대적인 트랜잭션 처리 작업 부하에서 새로운 용도를 발견했다.

설명

항법 액세스는 전통적으로 데이터베이스의 네트워크 모델 및 계층적 모델과 연관되며, 일반적으로 레코드(또는 개체)가 한 번에 하나씩 처리되는 데이터 조작 API를 반복적으로 설명한다. 그러나 바흐만이 설명한 본질적인 특성은 다른 기록과의 관계 때문에 기록을 찾는 것이다. 따라서 인터페이스는 설정 지향적 특징을 가지고 있다면 여전히 탐색적일 수 있다.[3] 이러한 관점에서 항법 데이터 조작 언어와 관계 언어의 주요 차이점은 가치 기반 결합보다는 명시적으로 명명된 관계를 사용하는 것이다. for department with name="Sales", find all employees in set department-employees 대 find employees, departments where employee.department-code = department.code and department.name="Sales".

그러나 실제로 대부분의 항법 API는 절차적이었다. 위의 쿼리는 다음의 의사 코드의 선을 따라 절차 논리를 사용하여 실행될 것이다. 

부서에 이름을 붙이다.'세일즈'가 설정 종료될 때까지 설정된 부서 직원의 첫 번째 직원 확보 {설정된 부서 직원 프로세스 직원의 다음 직원 확보 }

이러한 관점에서, 항법 API와 관계형 모델(관계형 데이터베이스에서 구현)의 주요 차이점은 관계형 API는 시스템에 무엇을 가져올지 묻는 "선언적"이나 로직 프로그래밍 기법을 사용하는 반면, 항법 API는 필요한 레코드에 어떻게 도달하는지를 단계별로 시스템에 지시한다.

항법 API에 대한 대부분의 비판은 다음 두 가지 범주 중 하나로 분류된다.

  • 사용성: 애플리케이션 코드를 빠르게 읽을 수 없게 되고 디버깅하기 어려움
  • 데이터 독립성: 데이터 구조가 변경될 때마다 애플리케이션 코드를 변경해야 함

수년 동안 내비게이션 API의 주요 방어는 성능이었다. 항법 API를 지원하는 데이터베이스 시스템은 한 레코드에서 다른 레코드까지의 물리적 링크나 포인터를 포함하는 내부 스토리지 구조를 사용하는 경우가 많다. 그러한 구조는 매우 효율적인 항해를 허용할 수 있지만, 데이터의 물리적 배치를 재구성하는 것이 어려워지기 때문에 단점이 있다. 낮은 수준의 포인터 추적(Bachman의 논문은 기본 키와 외부 키를 사용하는 관계형 시스템에서와 마찬가지로 논리적 관계가 구현되는 것을 예상함)없이 항법 API를 구현하는 것이 상당히 가능하므로 두 아이디어를 혼동해서는 안 된다. 그러나 낮은 수준의 포인터의 성능 이점이 없다면 탐색 API를 정당화하기가 더 어려워진다.

계층적 모델은 종종 계층의 각 수준에 나타나는 키를 연결하여 레코드의 기본 키를 구성한다. 그러한 복합 식별자는 컴퓨터 파일 이름에서 찾을 수 있다./usr/david/docs/index.txt(), URI, 듀이 십진법 및 우편 주소의 경우. 그러한 복합 키는 레코드에 대한 탐색 경로를 나타내는 것으로 간주할 수 있지만, 마찬가지로 연관 액세스를 허용하는 단순한 기본 키로 간주할 수 있다.

1980년대에 관계형 시스템이 부각되면서 항법 API(특히 절차형 API)가 비판받으며 인기를 잃었다. 그러나 1990년대는 선언적 인터페이스와 절차적 인터페이스를 모두 제공하는 객체 지향 데이터베이스의 새로운 흐름을 가져왔다. 이에 대한 한 가지 설명은 액세스가 본질적으로 재귀적인 그래프 구조 정보(예: 공간 데이터 및 엔지니어링 데이터)를 나타내기 위해 자주 사용되었다는 것이다: SQL(특히 1차 술어 미적분학)을 뒷받침하는 수학은 재귀 쿼리를 지원할 충분한 힘을 가지고 있지 않다. 전이성 폐업

인기 있는 탐색 API의 현재 예는 웹 브라우저에서 자주 사용되며 자바스크립트와 밀접하게 연관되어 있는 DOM(Document Object Model)에서 찾을 수 있다. DOM은 기본적으로 절차적 및 탐색적 API를 가진 메모리 내 계층적 데이터베이스다. 반대로 선언적·항행적으로 분류할 수 있는 XPath를 이용하여 동일한 데이터(XML 또는 HTML)에 접속할 수 있다: 데이터는 다음의 관계에 의해 접속되지만, 호출 프로그램은 순서대로 따라야 할 일련의 지시사항을 발행하지 않는다. 시맨틱 웹에서 Linked Data를 검색하는 데 사용되는 SPARQL과 같은 언어도 선언적이고 동시에 탐색적이다.

예

참고 항목

참조

  1. ^ Bachman, Charles W. (1973). "The programmer as navigator". Communications of the ACM. Portal.acm.org. 16 (11): 653–658. doi:10.1145/355611.362534. S2CID 18635540. Retrieved 2012-10-01.
  2. ^ Dionysios C. Tsichritzis and Frederick H. Lochovsky (1982). Data Models. Prentice-Hall. p. 67. ISBN 0-13-196428-3.
  3. ^ Błażewicz, Jacek; Królikowski, Zbyszko; Morzy, Tadeusz (2003). Handbook on Data and Management in Information Systems. Springer. p. 18. ISBN 3-540-43893-9.

외부 링크