database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Columns 949 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 949
Future Directions in DBMS Research
작성자
정재익(advance)
작성일
2004-03-25 08:42
조회수
14,657

소스 : "ftp://dblab.kyungwon.ac.kr/data/re001/vw/Future Directions in DBMS Research.htm"

읽어 볼만한 글이라서 원문 훼손않고, 그대로 올려 봅니다. 관심 있으신 분들 한번 읽어 보세요. DBMS 가 이런 분야도 있겠구나 하는 생각이 들것입니다. 아울러,  10년전인 1994년도 글인데도 상당한 안목을 가진 글이라고 생각됩니다. 여기 언급된 것들중에 몇가지는 벌써 구현되어 있지요. ^^;

 

Future Directions in DBMS Research

Readings in Database Systems, Morgan Kaufmann Publishers, Inc. 1994

Bernstein, Dayal, Dewitt, Gawlick, Gray, Jarke, Lindsay, Lockermann, Maier, Neuhold, Reuter, Rowe, Schek, Schmidt, Schrefl, Stonebraker 著

경원대학교 대학원 전자계산학과 데이터베이스 연구실

이기택, 서창석, 최현락, 남궁기찬, 오준환, 최지영 譯

1999.7.29

요 지

1988년 2월 4일에서 5일까지에 걸쳐 국제 컴퓨터 과학 연구소는 후원을 받아 데이터베이스 연구 학위 회원 중 16명의 상급 회원들이 데이터베이스 분야의 미래 연구에 관한 토론을 했다. 본 문서는 논의된 내용을 요약한 것이다.

1. 개 요

국제 컴퓨터 과학 연구소(ICSI)라 불리는 컴퓨터 과학 연구소는 버클리 캘리포니아 대학에 설립되었다. ICSI는 초기 자본을 컴퓨터 과학을 위한 독일 국제 연구 센터로부터 지원 받았고, 계속 후원을 받고 있다. 기초 전산학에서 연구 프로그램을 추구하는 데에 더해서 ICSI는 아이디어와 미국내의 컴퓨터 과학자와 다른 나라의 과학자들의 공동 연구 교환을 위한 권한을 갖고 있다. 그와 같은 자격으로 ICSI는 9명의 미국 DBMS 연구원과 7명의 독일 연구원이 참가한 캘리포니아의 Laguna Beach에서의 이틀간의 워크숍을 후원 받았다. 이 워크숍은 GMD의 Erich Neuhold과 Berkeley의 Michael Stonebraker에 의해 구성되었다.

워크숍의 목적은 미래에 대처하여 연구할 만한 DBMS 주제에 관하여 토의하는 것이었다. 첫날 동안 각 참여자들은 그들이 연구하지 않았지만, 그들이 중요하게 생각하고 연구하기를 원하는 4가지 주제를 소개하였다. 또한 각 참가자들은 그들이 중요한 연구 과정에서는 중요하지 않다고 생각되는 다른 사람이 연구한 두 가지 주제를 소개하도록 하였다. 그리고 모든 참가자들은 다른 사람들에 의해 제안된 연구 주제로 제안된 것 중에 다섯 개를 투표하여 선택하였다. 그들은 또한 과대 평가된 주제 2개를 투표하여 선택하였다. 투표와 더불어 첫날 일정은 "war stories"에 할애되었다. 즉, 실세계에서의 매우 어려운 데이터베이스의 문제를 연구함에 있어서 참가자들의 경험(war stories)을 얘기하였다. 두 번째 날에는 세부적으로 토의할 만한 주제들에 대하여 40분씩 토의하는데 할애되었다.

이 토의는 영향력이 컸으며, 몇몇 주제들에서는 중요한 동의가 있었다. 예를 들면, 참가자들은 사용자 인터페이스, active DBMS 그리고 병렬성의 연구의 중요성에 대부분 동의하였고, 나머지 대부분의 다른 주제들은 많은 지지를 받지 못했다. 참가자들은 하드웨어 데이터베이스 기계, 일반적인 반복적 질의 처리 그리고 DBMS와 prolog간의 인터페이스의 기여도에 대한 있을법한 연구에 대해서는 대부분 부정적이었다. 데이터베이스 tool kit에서의 연구의 중요성과 같은 다른 이슈들에 대해서는 참가자들의 의견이 분분하였다.

이 리포트는 개최된 토의를 요약한 것이다. 모든 참가자들은 이것을 준비하는데 기여하였고, 이 문서의 내용을 입증해 주었다.

이 보고서의 나머지 부분은 다음과 같이 구성된다. 2절에서는 DBMS가 사용될 만한 응용에 대해 논의하였고, 3절에서는 DBMS가 미래에 운영되는데 있어 요구되는 하드웨어 환경을 고려했고, 하드웨어 데이터베이스 기계의 실행 가능성에 대하여 논의하였다. 4절에서는 운영체제를 포함하는 다른 시스템 소프트웨어와 언어 프로세서를 포함하는 DBMS의 관계를 다루었다. 5절에서는 객체지향 DBMS라고 불리는 것을 포함하는 DBMS extension을 위한 메커니즘을 다루었다. 참가자들의 방식에 따라 6절에서는 Active DBMS를 다루었다. 7절에서는 최종 사용자 인터페이스와 응용 개발 도구를 주제로 다루었다. 8절에서는 single-site DBMS 구현을 위한 미래 기술의 연구를 다뤘다. 9절에서는 분산 DBMS에 대해 다루었다. 마지막으로 10절은 앞 절에서 다루지 않았던 주제들을 모아 구성하였다.

2. 미래의 응용(FUTURE APPLICATION)

몇몇 참가자들이 특정 응용 영역의 효과적인 연구 노력의 필요성 연구를 제안했다. 다른 참가자들은 특정한 연구 주제의 논의 또는 특정한 이슈에 대한 연구를 유도하는 예와 같은 새로운 응용 분야들을 다뤘다. 마지막으로, 많은 논쟁들은(many of the war stories) 새로운 응용 분야와 관련이 있다. 이 세션에서는 테마를 요약했다.

2.1 CASE

몇몇 참가자들은 DBMS 기술을 위한 중요한 새로운 응용 영역으로서 CASE에 초점을 맞추었다. 기본적으로, 모든 컴퓨터 프로그램(소스 코드, 문서, 프로그램 설계 등)과 같은 정보는 데이터베이스에 저장된다. 참가자들은 이 분야와 유사한 다른 많은 공학 응용분야(Versions, 복잡한 객체들, 상속 등)에서의 클라이언트들의 필요성을 생각했다. 현재 몇몇 상업 시스템들은 다른 상업 시스템들이 필요로 하는 고객 DBMS들을 구축하는 동안 CASE 데이터를 관리하기 위해 데이터베이스 시스템을 사용하고 있다. 일반적으로 CASE는 충분한 연구가치가 있는 연구 분야라는데 동의가 있었다. 예를 들어, 일반적인 "make" 기능(다시 말해, 어떤 모듈의 변경이 있을 때 자동으로 적절한 소프트웨어 모듈을 재 컴파일하는 것)을 설계하기 위한 좋은 방법은 강력한 트리거 기능을 지원하는 것이다. 위에 기술된 바 같이 active 데이터베이스에 관한 연구는 참가자들로부터 거의 만장일치에 가까운 지지는 받았다.

2.2 CIM

소수의 참여자들은 중요하고 새로운 응용 분야로서 CIM에 초점을 맞추었다. 여기서, 모든 공장 공정의 대부분의 절차들이 데이터베이스 시스템에 저장된다.(예를 들어, 기계 도구들을 위한 코드, 테스트 결과, 생산 스케줄 등등..). 참여자들은 새로운 데이터베이스를 이런 영역의 응용분야를 지원하는데 필요한 averters와 트리거와 같은 성능에 초점을 맞추었다. 이러한 영역에서의 일의 문제점을 지원하는 것도 고려해야 한다. 이러한 영역에서의 문제를 다루는 것에 대한 주목할 만한 지지가 있었다.

2.3 Images

참가자들 중의 두 명은 중요한 연구 영역으로서 자연적으로 생성된 데이터나 의학적 진단에서 발견되는 것(예를 들어, 위성 데이터)과 같은 이미지 응용 분야에 초점을 맞췄다. 논의는 이미지의 큰 bit string이 DBMS에 저장되는 것에 초점을 맞췄다. 큰 이미지의 저장을 접어두고, 참여자들은 다른 것들에 의해 이끌어져 와야만 하는 이런 분야에서의 중요한 패턴 인식 문제를 느꼈다.

2.4 Spatial Databases

몇몇 참여자는 어려운 응용들과 같은 공간적인 예를 다루었다. 이러한 예는 일반적으로 지도상에 현재 발견된 정보를 기호화된 지리적인 데이터베이스를 포함하는 것이다. 그 문제는 도시 서비스(예를 들어, 내가 X지점부터 Y지점까지 대중 교통수단으로 어떻게 효과적으로 갈 것인가?)를 제공하는 것부터 지구 표면 밑, 지구 표면, 지구 표면 위의 모든 종류의 데이터를 종합하는 환경 정보 시스템을 군사적 운영을 다루는데 이르기까지 다양화된다. 그러한 응용의 중요성을 위한 폭넓은 지원과 참여자들이 확장성 있는 DBMS들을 위해 이것이 매우 좋은 응용 분야라고 일반적으로 생각했다.

2.5 IR

한 명의 참가자는 정보 검색 응용의 필요성에 관한 연구가 중요하다고 생각했다. 기본적으로 그는 많은 데이터베이스 응용의 요소가 되는 텍스트, 오늘날 일반적인 키워드 중심의 검색 그리고, 다시 고려되어야 하는 정보 검색 응용을 생각했다. 이것의 목적은 IR 시스템이 1회용 응용 프로그램으로 생각되지 않도록 하는 것과 이 분야에서 일반화된 DBMS의 능력이 지속되기 위하여 semantic과 객체지향모델을 가진 이러한 분야에서 클라이언트의 요구를 효과적으로 충족시켜주는 것이다. 이러한 관점에서 몇몇 흥미로운 것이 나타났다.

3. 미래의 하드웨어 환경

3.1 혁명

몇몇 참여자들은 지적했다. 특히, 최근 20년 동안 개개의 CPU의 속도가 약 5년의 일정한 비율로 약 1 MIP에서 15 MIPs까지 증가되어 왔다. 다음 몇몇 동안은 RISC 기술로 인해 약 1-2년을 단위로 CPU의 속도가 더욱더 빨라 질 것이다. 이러한 CPU 기술의 빠른 성장을 통해 DBMS나 OS, 사용자 인터페이스 등에 있어서 굉장한 영향을 가져 올 것이다. 참여자들은 약 10만 달러에 판매되고 있는 50 MIPs의 CPU와 GB의 메인 메모리를 가진 머신에 대해 토의했고 예를 들어 "만약 당신의 데이터베이스에 적합한 메모리가 없다면, 몇 달 만 기다리면 해결될 것이다."내용이 토론되었다.

다음 몇 년 동안 자원(CPUs, Memory, Disk)의 가격이 내려가는 속도만큼 적어도 클라이언트 애플리케이션의 필요성이 증가할 것인지에 대한 폭 넓은 토의가 있었다. 자원에 대한 일정한 필요성을 갖는 애플리케이션의 비용이 위에서 언급한 바와 같이 다음 몇 년 동안 1년에 두 번에 비율로 줄어들 것이다. 가장 값싼 하드웨어를 통해 일정한 애플리케이션을 가진 클라이언트의 비용문제가 해결될 수 있을 것이며 성능 또한 조만간 시시한 일이 될 것이다. DBMS가 중요한 연구 분야에 계속 사용되기 위해서는 하드웨어의 가격이 빠르게 내려가는 만큼 적어도 클라이언트의 필요성이 증가되는 것이 필요하다.

DBMS 클라이언트는 값싼 자원들을 최대한으로 활용하는데 있어서 적합하지 않다는 문제점에 대한 협정이었다. 몇몇 참여자들은 의사지원 애플리케이션은 현재 너무 고가이므로 자주 사용되지 않을 것이라는 점을 보고했다. 하드웨어의 가격이 점점 내려간다면 분명히 이러한 종류의 애플리케이션도 사용될 것이다. 다른 사람들은 클라이언트가 인간의 생산력에 근거해 자원의 사용이 증가되는 것을 당연한 것이라고 주장한다. 예를 들어, 배치작업보다는 사용자와 상호작용 하면서 실 시간적인 응답을 제공하는데 있어서 추가적인 하드웨어가 사용될 것이다. 몇몇 참여자들은 현재 실세계의 데이터베이스가 매년 30 - 50 % 씩 성장하고 있으며, 이러한 성장은 감소하지 않을 것이라 주장한다. 그러므로 디스크에 가격이 내려가는 비율에 따라 공간에 대한 소비는 증가할 것이다. 다른 참여자들은 적어도 하드웨어의 비용이 줄어드는 비율에 따라 DBMS의 기능이 증가될 것이며 DBMS의 성능 또한 계속 쟁점화될 것이다. 최근 들어, 한 참여자는 정보를 유지하고 새롭게 만드는 데에 있어서 상당한 량의 자원을 소비하는 과학적인 공동체에 언급하고 있다.

데이터에 접근하는데 있어서의 자원의 관리는 미래에 있어서 중요한 문제가 될 것이다. 이러한 단지 시나리오에 방해가 되는 것은 DBMS와 그들의 클라이언트가 향상된 기능의 새로운 소프트웨어와 더욱 빠른 애플리케이션을 작성하는데 사용할 수 없다는 것이다.

·MIP : Million Instructions Per Second, 컴퓨터의 연산 속도를 표시하는 단위로 CPU가 1초간에 실행할 수 있는 명령수의 평균값을 100만 개 단위로 표시

·RISC : Reduced Instruction Set Computer

3.2 데이터베이스 기계

하드웨어에 대한 조사에 있어서 DBMS 머신이 성능에 있어서 중요한 결과를 나타내는 것이 아니라는 압도적인 의견이 있다. 몇몇 사람들은 하드웨어의 선정과 종류에 있어서 더 이상의 문서를 읽지 않아도 된다고 말하고 있다. 일반적인 목적의 CPU의 가격이 매우 빠르게 내려가고 있으므로 주문 설계된 하드웨어보다 오히려 일반적인 목적의 하드웨어에서 소프트웨어로서의 DBMS 기능이 주가 될 것이다. 그러나, 주문 설계된 하드웨어가 가까운 미래에 있어서 일반적인 목적의 CPU와 경쟁할 수 있다는 점에 대해 낙관할 사람을 아무도 없다.

4. 미래의 소프트웨어 환경

4.1 운영체제

운영체제는 특히, 파일 관리에 있어서 데이터베이스 연구자들로부터 잘못된 종류의 서비스를 제공하는데 대한 많은 비평을 받는다. 참여자들의 의견은 이러한 문제가 곧 해결되지 않을 것이라는데 있어서 일치한다. 운영체제의 설계자들도 다음 몇 년 동안 미래에 머신에 존재하게 될 대량의 메모리와 CPU의 처리속도에 증가로 인해 네트워킹 소프트웨어와 실질적인 커널 부분의 변경에 있어서 매우 바쁠 것이라는 것을 느껴왔다. 이러한 새로운 통신 프로토콜은 곧 ISO와 특별한 목적의 프로토콜(예, NFS)로 포함될 것이다. 추가적으로 미래의 운영체제의 설계자는 빠른 재실행과 계속적인 연산과 고장 관리와 운영체제의 재구성에 있어서 작은 커널이 필요성과 최상의 계층화된 서비스를 제공하기 위해서 주목해야 할 것이다.

운영체제는 DBMS의 필요에 더욱 빠르게 응답할 것이라는 기대가 있다. 이러한 희망은 단지 트랜잭션 관리라는 하나의 영역에 관한 것이다. 몇몇 참여자들은 트랜잭션을 처리하기 위해 확장된 서브시스템(예, 서로 다른 두 개의 데이터 관리자 또는 데이터 관리자와 네트워크 관리자)의 필요성을 지적하고 있다. 이러한 필요성은 단지 트랜잭션 지원이 내장된 커널 또는 적어도 DBMS의 외부에서 제기될 수 있다. 소수의 입장에서는 이러한 분류의 문제가 당연히 이질적인 분산 DBMS문제로써 제기된다고 생각한다. 이러한 해결책은 단지 DBMS의 환경내에서 트랜잭션의 행위들을 유지할 수 있다면 만족스러울 것이다.

몇몇 사람들은 데이터베이스를 위한 운영체제의 지원이 매우 중요한 연구 분야라고 지적하고 있다. 한 참여자는 데이터를 접근하는데 있어서 초당 10M 바이트의 속도가 필요한 애플리케이션에 대해 논의하였다. 이러한 성능은 단지 병렬적으로 다수에 디스크에 있는 데이터를 접근·읽기를 통해 이룰 수 있다. DBMS 애플리케이션을 위한 고성능의 파일 시스템에 대한 연구가 지원되고 있다.

또한 논의는 현재 운영체제의 인터페이스가 보존될 것인지에 집중된다. 모든 사람은 현재의 인터페이스가 오랜 시간 동안 강요되어 왔다고 생각한다. 마찬가지로 클라이언트 또한 SQL에 의해 강요되어 왔다.

4.2 프로그래밍 언어 인터페이스

현재의 DBMS와 프로그래밍 언어사이에 인터페이스에 있어서 어려운 부분에 대한 논의가 있다. 몇몇 참여자들은 내장된 그리고 동적인 질의를 위해 현재의 매우 강력한 SQL 인터페이스를 정리하는 것이 중요하다고 느낀다. 다른 사람들은 대부분의 사용자가 4GL로 코딩할 것이며 이러한 단계는 숨겨져 있을 것이며 덜 중요할 것이다. 데이터베이스 서비스를 호출하도록 만들어진 일반적인 프로그래밍 언어로 작성된 많은 프로그램과 보기 좋은 인터페이스는 투자할 만한 분야이라는데 관심이 집중된다. 더욱이, 누군가 4GL 인터프리터와 컴파일러로 작성해야 한다면 이러한 사람은 말끔한 인터페이스에 대해 알 수 있을 것이다.

표준 4GL에 대한 가능성은 간결하게 언급했다. 누구도 정치적인 문제에 관계된 어떠한 부분에 있어서는 표현할 수 없을 것이다. 몇 년 내로 4GL에 대한 표준이 생길 것이다.

4.3 Prolog

현재 프롤로그와 DBMS사이에 있어서의 인터페이스에 대한 연구는 상당한 것이다. 많은 참여자들은 이러한 분야가 상당한 영향력을 가질 것이라고 말하고 있다. 많은 연구 그룹들은 똑 같이 느끼고 있다. 더욱이, 대부분의 사람들은 실세계의 문제가 논리적인 부분과 규칙 체계 부분이 데이터 관리자로 통합될 것이다. 외부의 규칙 관리자와 DBMS사이에 상호작용에 있어서 효율적인 'glue'로 해결하는 것이 그리 흥미가 있는 일이 아니다. 많은 참여자들은 이러한 분야에 프로젝트에 자금 지원을 중단해야 한다는 의견을 보인다.

5. 확장 가능한 데이터 관리자

이틀간의 워크숍(workshop) 동안 이 영역의 주제들을 여러 차례 논의하였다. 참여자들은 CASE, CIM과 공간 응용들이 새로운 종류의 객체들을 요구한다고 지적하였다. 특히, 기본 객체 형태의 작은 집합에서는 이 분야에 대하여 동의된 것이 없었으며, 확장 가능한 DBMS들은 이들 응용들의 필요에 대한 유일한 해결책으로 보았다. 토론은 확장구조와 객체 지향형 데이터베이스로 자연스럽게 나눠졌으며, 차례로 각 영역을 살펴보기로 한다.

5.1 확장 구조(Extension Architectures)

이 영역에서는 실질적인 논쟁이 있었다. 구문분석, 질의 최적화, 접근방법, 트랜잭션 관리 등과 full-function DBMS의 문맥 속에서 사용자의 확장성을 지원하는 완전한 DBMS를 만드는 데 몇몇 사람들은 호의적이었다. 이런 접근은 POSTGRES, PROBE, STARBURST, 그리고 VODAK에서 시도되고 있다. 반면에, 다른 사람들은 모듈 설계자가 기존의 시스템에 함께 넣을 수 있도록 세련된 애플리케이션 설계를 지원하는 툴킷 접근법에 관심이 높았다. 이 접근법은 DASDB, GENESIS, 그리고 EXODUS에서 연구되고 있다. 토의에서는 이런 선택사항들 사이에서 뜨거운 논쟁이 있었으므로, 몇몇 사항들을 정리하면 아래와 같다.

툴킷 접근법을 옹호하는 사람들은 "세련된 사용자는 툴킷 내 에서 이용 가능한 몇몇 것들로부터 자신이 소유한 동시 실행가능 회복모듈 컨트롤을 설치할 수 있다"라고 주장하였다. 이렇게 하여, 주문형 트랜잭션 관리기가 만들어 질 수 있었다. 또한 그들은 CASE처럼 "lean and mean" 시스템이 단지 요구되는 능력만을 포함하도록 만들어 질 수 있는 응용 영역을 지적하였다.

확장 가능한 시스템을 옹호하는 사람들은 트랜잭션 관리 코드는 빠르고 오류로부터 자유롭게 만들기에 가장 어려운 것들 중의 하나라고 주장하였다. 그러므로, 그것은 일단 DBMS super-wizard에 의해서 수행되어야 하고 심지어 세련된 사용자들이 super-wizard가 할 수 있는 것보다 더 잘 하기를 기대하는 것은 비현실적이다. 뿐만 아니라, 트랜잭션 관리기의 성능은 필요하다면 super-wizard에 의해 설치되어야 한다.

확장 가능한 시스템을 옹호하는 사람들의 두 번째 논제 포인트는 대부분의 응용이 질의어, 최적화, 범용 실행시간 시스템을 포함하는 full-function 시스템을 요구하는 것처럼 보인다는 것이었다. 한 사용자가 full-function 시스템을 필요로 한다면, 툴킷 접근은 적절하지 못하다.

참여자들은 이 두 가지 관점의 장점들 사이에서 동등하게 나뉘어졌다. 특히, 한 참여자는 확장의 스펙트럼이 있다는 것과 툴킷과 확장 가능한 시스템이 가능성의 연속선상에서 단지 다른 위치에 있다고 지적하였다. 예를 들면, 확장 가능한 시스템은 자료형의 포함이나 대체를 허용하는 동안 질의어를 다른 어떤 것으로 바꾸는 것을 허용하지 않는다. 반면에, 툴킷 접근은 양쪽 모두의 조건을 제공한다. 따라서, 툴킷은 확장 가능한 시스템의 확장 가능성을 제공한다.

명백하게도, 확장 가능한 시스템의 구조는 훌륭한 연구분야이다. 더욱이 여러 참여자들은 확장 가능한 데이터베이스 시스템을 최적화하는 방안 속에서 연구의 중요성을 토론하였다. 그러므로, 하급 접근 경로나 조인 알고리즘에 대한 지식을 쉽게 코드화 하는 질의 최적화와 수행 시스템에 대한 연구가 중요하다고 폭넓게 믿어졌다. 여러 참여자들은 설계 환경 사이에서의 차이, 예를 들면 확장 가능한 DBMS의 구성에 대한 것이라든가, 스키마를 평가하는 것, 성능 조정(performance tuning) 하는 것, 그리고 확장 가능한 시스템의 복잡성의 사용환경이 컴파일되고 최적화되는 것 등에 대한 이점을 지적하였다. 그렇지만 결국 두 환경 모두 단일 구조와 시스템에서 반영되어야 한다.

5.2. 객체 지향 데이터베이스

이 토픽은 오랫동안 진행되었던 토론이었다. 일부 참여자들은 이 분야 모두가 잘못 인도되었다고 생각했다. 반면에 다른 참여자들은 그것이 매우 중요한 연구분야라고 생각하였다. 사실상, 모든 참여자들은 이 연구분야에서 각각 강한 의견을 굽히지 않았다. 절반은 결과에 대한 보장이 없다고 생각하였고, 다른 절반은 중대한 결과가 얻어질 수 있는 분야라고 생각하였다. 이것이 모순 명제로 보인 것은 그 제안자와 비방자가 그들이 객체 지향 데이터 베이스(OODB)라는 단어를 사용했을 때 서로 다른 가능성에 대해 토의하고 있었다는 것을 발견했다는 사실에 의해 설명될 수 있다.

그러므로 OODB라는 용어는 연구공동체에서 공통된 정의가 내려지지 않고 있다는 것이 분명하다. 참여자들은 이 영역에서 공통된 용어들을 사용하고, 그들이 얻고자 하는 공통 목표를 규정하기 위해 연구원들을 강압할 수 있는 눈에 보이는 대변인이 보이지 않는 사실을 안타까워하였다. 이러한 상황은 Ted Codd가 singlehandedly 관계모델을 정의한 1970년 초와는 대조적인 것이었다.

OODB연구의 제안자들은 두 가지의 주요한 사항을 지적하였다. 첫 번째로, 그들은 OODB가 확장 가능한 DBMS를 구성하기에 적합한 프레임워크라는 것을 주장하였다. 이 분야에서 연구원들은 사용자가 OODB 자체의 데이터 언어를 사용하는 연구원 자신이 소유한 타입들과 연산자들을 쓸 수 있는 시스템을 구성하고 있다. OODB의 첫 번째 목적은 확장 가능한 데이터 관리의 옹호자들의 목표와 유사하다. 그러나, 이 데이터베이스에서 확장은 종종 그것의 데이터 언어가 아닌 OODB의 구현언어 속에서 새로운 데이터타입과 연산자를 쓰는 것을 통해 이루어진다. 그렇지만, OODB 제안자들의 일부는 OODB가 그것을 다시 보다 많이 유사하게 확장 가능한 데이터 관리자로 만들어서 다양한 프로그래밍 언어들로 쓰여진 프로시저들에 연결되고 호출되는 능력을 갖추어야 한다고 지적하였다. 추가로 그것은 객체지향 패러다임이 정의된 오퍼레이션이 강요되고 관리될 수 있는 것과 대조되는 프레임웍을 제공한다는 것으로써 입증될 수 있다. 이것은 확장 가능한 시스템이 컨트롤 할 수 없는 작동상태가 야기될 때의 모든 문제들을 피할 수 있을 것이다.

반대론자들의 두 번째 지적사항은 많은 연구원들이 OODB라는 용어를 객체의 본질을 지원하는 저장관리자로 사용하는데, 객체는 다른 객체들의 식별자를 포함하는 필드들을 가질 수 있으며, 다음의 작업을 수행할 수 있다고 생각한다.

객체 식별자가 주어지면, 객체 인스턴스를 가져온다.

객체 인스턴스가 주어지면, 객체의 어느 필드든지 찾는다.

인터페이스의 이 단계에서는 객체 식별자를 얻는 것을 프로그래머에게 요구하고, 그런 후에 객체 안에 있는 필드들인 객체 식별자들을 획득함으로써 다른 객체들을 항해할 수 있다. 이것은 여러 CODASYL 시스템 참여자들을 상기시켰고, 그 참여자들의 심각한 문제들은 1970년대 중반에 장기간 동안 논의되었었다. 이 인터페이스의 클래스는 따라서 1970년대를 회상하고 잘못 인도된 노력으로 참조되었다.

이런 입장들은 실제로 서로 충돌을 일으키지 않는다. 대부분의 OODB 제안자들은 record-at-a-time 항해법을 방어하지 못하였다. 오직 한 쌍의 참여자들만이 이 인터페이스가 적합할 것이라는 애플리케이션 영역을 인정하였다. 모든 이들이 OODB가 값 기반의 조인을 포함하는 질의어나 그런 질의들을 처리하기 위해 실력 있는 데이터 관리자에 따라 집합단위 연산을 하는 다른 방법을 가져야 한다고 생각했다. OODB 참여자들은 일반적으로 계승이 좋은 아이디어라고 생각했고, 모든 사람들이 확장에 호의적이었다.

그러므로, 그 실제 문제는 객체지향이 너무 많은 다른 것들을 의미하고 있다는 것이다. 용어들이 안정되고 어떤 시스템 목적의 명분이 나타날 때까지 우리는 우리가 그러했듯이 용어가 의미하는 공통된 것을 구하지 못했다는 것을 깨달으면서 다른 사람들이 많은 토의 시간을 소비할 것을 우려한다.

6 .활동적인 데이터베이스와 룰 시스템

많은 관계자들이 이른바 활동적인 데이터베이스의 필요성을 지적하였다. 그러므로, 트리거(triggers), 얼러터(alerters), 제약조건(constraints) 등은 서비스로서 데이터베이스 시스템에 의해서 지원되어야 한다. 이 능력은 데이터 베이스의 장래 애플리케이션들의 필요성으로서 가장 자주 언급된 것 들 중의 하나였다. 미래의 시스템에 대한 연구영역에서의 주요한 승리를 하게 될 이 서비스를 제공하자는 강한 견해 일치가 있었다.

다수의 관계자들은 현재의 상업적인 시스템이 데이터베이스 시스템 컨트롤 아래 실행될 수 있는 데이터베이스 객체로서 설치(install)된다고 지적했다. 많은 경우에 , 그러한 절차(procedure)들은 응용 프로그램에 의해서 곧바로 불러진다. 그러한 절차들이 데이터베이스에서 조건들의 결과로 불러지도록 허락하는 것은 단지 조금 더 복잡하다. 그러므로, 활동적인 절차들과 활동적인 데이터베이스는 단일 서비스로서 함께 참작되어야 한다. 그 관계자들은 지금 상업적인 시스템이 이 영역에 있어서 문법과 관련된 하찮은 일을 하는 것처럼 보이기 때문에, 절차들을 위해 보다 현명한 문법을 규정하는 연구원들의 명백한 필요성을 지적했다.

또한 활동적인 데이터베이스 시스템이 극히 높은 성능을 갖는 단순한 규칙들을 갖어야 하는 것은 만장일치하였다. 질문은 전문 시스템의 주서 아래 AI 연구원들에 의해서 정상적으로 할당되며, 완전히 회피되어야 한다.( 예를 들면 안전을 증명하기 위하여 원리 시험이나 규칙의 상호 일관성을 실행하는 것). 한 관계자는 데이터베이스 시스템은 마음먹은 대로 간단히 규칙을 깨뜨리며 데이터베이스 시스템 상태를 활동적인 규칙으로 기억하는 것을 지적했다. 만약 그 실행중인 시스템이 다시 같은 상태로 되돌아갔다면, 그러면 불일치 혹은 불안정이 나타난다. 그와 같이 케이스에, 그 데이터베이스 시스템은 오직 현재의 트랜잭션을 전의 상태로의 복귀를 위해 중지하는 것만이 필요하다. 이와 같은 단순한 해법들은 보편적으로 원리 증명을 시도하는 관계자들에 의해서 제시되었다.

사용자에 의해서 또는 반복적인 규칙들의 활동의 결과에 의해서 제출된 반복적인 질의들을 능률적으로 해결하는데 있어서 현재 실질적인 연구 활동이 있다. 그 관계자들은 부품 전개 또는 이행적인 종결 질의로 많은 클라이언트들이 있다고 생각했다. 그래프에 있어서 최단 경로 문제들과 같은 순차 반복적인 질의들로 또한 많은 클라이언트들이 있다. 그러나, 참여자들 중 어느 누구도 일반 규칙을 코딩하고 최적화 함에 의해서 가장 잘 풀어졌던 애플리케이션을 참조하지 못하였다. 그러한 것으로써 , 반복적인 질의들의 해법들을 위해 클라이언트가 있는 것은 명백하지 않다. 관계자 대다수의 압도적인 감정은 그들이 이 영역에서 더 이상의 논문들을 참조하기를 원하지 않았던 것이다. 게다가, 그들은 지금 회의들이 순환적인 질문 처리에 너무 많은 논문들을 받아들이고 있다고 불평하였다.

유추는 사색적인 연구 공동체에 의해서 처음으로 몇 년 전 마침내 탐사되었던 종속성 이론으로 다가가게 되었다. 대부분의 관계자들은 이 긴 연구가 실질적인 중요성에는 거의 기여하지 않았던 것, 그리고 일반적인 순환 질문 처리가 같은 운명에 직면할 것이라고 생각하였다.

한 관계자는 지식 획득이 본래의 목적이었던 것을 기억하였다 그리고 규칙에 있어서 어려운 문제는 애플리케이션들을 기준으로 하였다. 그 연구집회의 생각은 이 과제가 정말 어렵다는 것이었다. 소수의 참여자는 중요한 발전들이 이 영역에 연구에서 결과로서 생길 것이라고 생각하였다.

7. 최종 사용자 인터페이스

그 관계자들은 실질적으로 더 좋은 사용자 인터페이스나 더 좋은 데이터베이스 어플리케이션 개발 툴을 연구하는 연구원들이 없다는 것을 직시하였다. 지난 몇 해동안 단지 이 영역에는 출판된 논문이라고는 여기 저기에 몇 편밖에 없었다. 이 분야가 정말 중요한 분야이고, 다른 영역보다 관계자들에 의해서 더 많은 지원을 받았다는 전반적인 견해 일치가 있었다. 추가로, 몇몇 관계자들은 지난 10년간 사용자 인터페이스와 관련된 non-데이터베이스에서 주요한 발전이 있었다는 것을 지적하였다. 그들은 그 스프레드시트들, WYSIWYG 인터페이스들, Hypercard, 등이 휴먼 인터페이스들에서 완전한 혁명의 원인이 되었다는 것을 직시했다.

그 토론은 " 왜 주요한 발전이 데이터베이스 연구 학회의 참여없이 매우 중요한 영역에서 이루어지고 또한 그 상황을 바꾸려면 어떻게 해야 하는가?" 라는 명백한 질문으로 향하였다. 다수의 요점들은 토론에서 발생하였다. 첫 번째로, 사용자 인터페이스들에 관한 출판된 논문들은 본질적으로 난해하다는 것이 지적되었다. 한 관계자가 "가장 좋은 사용자 인터페이스는 설명서를 필요로 하지 않는다 "라고 지적했다. 그러므로, 어떻게 그러한 인터페이스들의 본질을 포착하는 논문을 쓸 수 있는가? 두 번째 요점은 그 학회는(특별히 프로그램 위원회) 그들이 전형적으로 방정식 혹은 "어려운 지식인의 " 내용을 가지고 있지 않기 때문에 사용자 인터페이스 논문에 적대시하는 것이었다. 세 번째 요점은 사용자 인터페이스 공헌이 그들의 가치들을 평가하기 위해 구축되어야만 한다는 것이었다. 한 참여자는 견해를 증명하기 위하여 "demo or die"를 주장하였다. 그러나, 실재 시스템을 구축하기 위해 사실상의 인터페이스가 구축될 수 있기 전에 구성되어야만 하는 거대한 양의 저급의 지원 코드가 있다. 이 "기반 구조"는 겨우 최근에 X11과 같은 툴 킷들의 모양으로 사용 가능하게 되었다.

그 관계자들은 마지막 요점 때문에 사용자 인터페이스들에 영향을 미치는 것이 더 쉬우며 미래에 이 영역에 있어서 더 많은 작업이 있다는 것을 알았다. 그들 중 거의 1/3은 그들이 한 종류 혹은 또 하나의 최종 사용자 인터페이스에 관련해서 일하고 있다고 말하였다. 토론에서 발생하였던 건설적인 의견은 SIGMOD와 VLDB과 같은 국제적인 모임들이 연구원들이 논문 형식보다 오히려 비디오에서 생각을 기여할 수 있도록 비디오 트랙을 놓아야만 한다는 것이었다. 프로그램 위원회 자신들의 그러한 흐름은 사용자 인터페이스 공헌에 분명히 향하게 될 것이고 최근 OOPSLA 회의들에 의해서 성공적으로 사용되었다. 총괄하여, 우리들은 이 제안을 실현하기 위한 그러한 모임들의 주최자들을 열심히 격려할 것이다.

8. 단일 사이트 DBMS 기술

이 주제에서는 규칙을 변경하는 처리에 관한 기술이 조금 논의되었다. 여기에 기여하는 요인들은 저렴한 가격으로 더욱더 높은 성능을 필요로 하는 것으로써 처리장치 그리고 공유 메모리 구성, 주기억장치의 giga 바이트, 그리고 3 1/2" 또는 5 1/4" 드라이브들의 큰 배열이 있다. 이 기술은 질의 최적화, 실행 기법과 새로운 환경을 위한 실행 시간 시스템을 다시 생각하게 할 것이다.

두 번째 사항은 높은 가용성과 더욱더 좋은 장애 처리를 위한 필요성이다. 아무도 이 영역의 문제들이 간단하다고 생각하지 않는다. 왜냐하면 중요한 결과가 매우 낮은 수준의 '상세한' 엔지니어링 작업을 야기할 지 모르기 때문이다.

더 이상 병행 제어 논문들이 전통적인 데이터베이스 트랜잭션 모델을 위해 작성되지 않아야 한다는데 광범위한 의견의 일치가 있었다. 대부분의 참여자들은 이 영역의 논문들이 과거 연구에서 "미세한 변형들"이기 쉽다고 생각하였으며 이 영역의 알고리즘들에 미래 연구는 감소되어야 한다는 것이다. 또 한편으로는, 새로운 트랜잭션의 자료 모형 연구에 많은 노력이 있었다. 직렬성과 원자성의 표준안 개념은 15년 동안 변하지 않았다. 중첩된 트랜잭션과 SAGAS와 같은 특별한 묘안들도 있었다. 그러나 모임의 센스는 CIM이나 CASE와 같은 새로운 응용영역이 더욱 설득력 있는 이익을 얻는다는 것이었다. 그러한 모형은 다음 사항들을 포함한다.

1) 버전 제어를 하는 Check-In Check-out 프로토콜

2) 직렬성 보다 약한 의미론

3) 완료 한 후에 되돌릴 수 있는 트랜잭션

그 모형이 보이려고 했던 것이 무엇인지, 그것이 필요했었는지에 대해서는 의견의 일치가 없었다. 참여자들은 이 분야의 연구를 지원하겠다고 입을 모았다.

병렬처리 연구에도 강력한 지지 발언들이 있었다. 기본적으로, 이것은 단일 질의 명령을 위해서 다중 질의 계획들을 실행하는 것과 마찬가지이다. 이 전술은 다중 디스크를 사용하기 위한 단일 CPU 시스템에서 도움이 된다. 공유 메모리 시스템에서는 다중 처리장치들을 이용하는 것이 바람직하며 명백하게 그것은 밀 결합 분산된 시스템의 핵심 기술이다. 이 영역의 연구에서 그 큰 이익은 사용자에게 로크 시간을 짧게 유지하는 능력뿐만 아니라 실시간 응답으로 보여주는 능력이다. 사용자 인터페이스 연구와 active 데이터베이스가 가장 많은 지원을 받았다

보다 좋은 성능을 이루게 하는 사소한 기술에 관한 연구에 약간의 흥미가 있었다. 많이 사용되는 구역을 제거하는, 작업 질의에 대한 응답을 캐슁하는 것 그리고 몇 가지의 정렬과 사전에 연산된 조인들이 흥미 있는 분야였다. 각 아이디어들은 성취한 만큼 흥미가 있었으나 제한된 범위의 아이디어라고 간주되었다.

마지막으로 접근방식 연구에 매우 반대하였던 참여자들이 있었다 그들은 그들이 B-트리와 확장 가능한 해싱에 충분한 변형들을 참조하였던 것을 생각하고 이 영역의 논문들에 더 이상 관심을 두지 않는다. 최근 논문들이 같은 테마들의 컬렉션이었던 것, 그리고 오직 10-20%의 성능 증가가 그러한 생각의 결과라는 것이었다. 몇 몇 참여자들은 몇 몇 상업적인 벤더들이 최근에 그들의 데이터베이스 시스템을 다시 만들었지만 확장 가능한 해싱이나 개선된 B-트리를 사용하지 않았다고 지적하였다. 그 이유는 그들이 이 분야의 기술로 코딩하는 것이 결코 이익이 아니라는 것이었다. 그러나 몇 몇 참여자들은 객체들의(eg. 공간 객체) 새로운 클래스를 지원하는 새로운 접근방식에 대한 연구가 필요하다고 지적하였다.

9. 분산 DBMS

참여자들은 연구학회가 분산 데이터 베이스 관리 시스템을 지난 10년 동안 조사했다고 생각하였다. 지금 이 영역에는 강력한 상업적인 활동이 있었으며 몇몇 벤더들이 이질 분산 DBMS에 매우 힘든 연구를 하고 있다. 이 영역에 정말로 힘든 문제들은 큰 분산 컴퓨팅 시스템( 50,000 단말기를 말하다 )의 시스템 관리이다. 이 환경을( e.g 모듈들의 새로운 갱신들을 설치하는 것, 새로운 사용자들) 관리하는 것은 현 시스템에 중요한 문제점이다. 연구원들은 이 분양의 영역에 경험이 있어야 기여하기 때문에 이 문제에 대해서 도움을 줄 수 있는 것이 거의 없다고 느껴졌다. 크고 복잡한 시스템을 연구 할 수 있는 위치에 있는 연구원들은 거의 없었다.

지원을 필요로 하는 분산 데이터 베이스의 유일한 문제는 규모이다. 데이터 베이스는 백 개 혹은 심지어 수 천 개의 노드를 포함하는 시스템일 것이다. CIM 환경들은 워크스테이션 데이터 베이스가 존재하는 환경들과 마찬가지로 아니라 많은 수의 노드들을 가지고 있을 것이다. 많은 수의 노드들로 확장하려는 관점에서는 질의 처리, 복제, 트랜잭션관리, 충돌회복을 위한 알고리즘들을 재고하는데 지원이 있었다. 그러나, 다른 참여자들은 상업적인 회사들이 연구 공동체보다 더 빠르게 이 영역에 진출했기 때문에 시간의 낭비가 있었을 것이라고 말하였다.

10. 다방면에 걸친 주제들.

10.1 물리적인 데이터베이스 설계

물리적인 스키마를 선택하고, 그 다음에 필요할 때 스키마 변환시 성능을 모니터할 자동 물리적 데이터베이스 설계 도구들을 연구자들이 구축해야 한다는데 견해가 일치하였다. 이것은 인덱스들을 추가하고 삭제하는 것을 포함하고 상당수의 디스크 암(disk arm)들을 교차하는데 암(arm) 동작 균등화 작업을 실행시킨다. 그러므로 손잡이들을 조정하는 작업은 데이터베이스 관리자(DBA)의 도메인에서 제거되고, 시스템 데몬(demon)에 의해서 조작되어야 한다. 이 방식에 많은 지지 견해가 있었고, 대부분의 사람들은 그것이 단지 중간 정도의 힘든 문제라고 생각하였다.

10.2 설계 도구들

다수의 참여자들은 현재의 데이터베이스 설계 도구들이 단지 그래픽적인 시스템인 것에 주목하였다. 현재는 상업적으로 사용 가능한 상품들의 종류가 많이 있다. 그러므로 그들의 연구 주장은 설득력이 약하다. 둘 셋의 참여자들은 객체를 위한 방법론적 개념들을 포함한 확장된 설계 도구 객체, 작동과 제약에 관심을 표명하였다.

10.3 실시간 데이터베이스

실시간으로 실행해야 하는 응용들의 필요성에 대하여 상당 시간 토론되었다. 일반적으로 응용들을 모니터링 하는 것은 데이터베이스에 끊임없는 데이터 스트림을 입력하는 것이다. 종종, 그들은 일단 그것이 더 이상 시기적절하지 않으면 데이터를 버린다. 여러 번 처리해야 할 데드라인이 있다(즉 DBMS는 조립공정에서 부품이 로봇 팔로 지나칠 때쯤 반응해야 한다.). 이러한 환경에서 트랜잭션의 개념은 불명확하고, 트리거에 대한 필요성들이 명백해진다. 이런 이슈들에 유의하도록 이 분야에서의 연구 지원이 있다.

10.4 데이터 모델

데이터 모델들을 위한 지원은 더 이상 없었다. 그 참여자들은 우리들이 이미 충분하게 가지고 있다라고 보편적으로 생각하였다. 또한 공통적으로 " 차세대 " 데이터 모델의 표준화를 위한 시도에 대한 지원은 미약했다. 이것은 단지 또 다른 데이터 모델을 발명하는 것과 마찬가지로 좌절을 연습하는 것으로 느껴졌다. 그러나 그것은 객체지향 데이터베이스와 액티브 데이터베이스도 같은 방법으로 자신의 데이터 모델을 제공하는 게 되었다. 전통적인 모델들과 대조적으로 이 데이터 모델들은 고정되어 있지 않지만, 각각 해당 정의 능력을 통하여 동적으로 변경 가능하다.

10.5 데이터 변환

한 사람의 참여자가 이질 컴퓨팅 환경에서 데이터 변환 문제를 제기하였다. 따라서 이 분야를 논의하였으며 대부분의 사람들은 이것은 이미 해결된 연구 주제라고 간주하였다. 1970년대 초반의 학문에서 적합한 구조들을 포함하고 있었으며 실세계 데이터 변환 시스템은 꽤 여러 해동안 관련 분야에 전개되어 왔다.

10.6 데이터베이스들에 의한 정보교환

둘 셋의 참여자들은 정보교환과 협동작업 문제를 제기하였다. 그들은 많은 응용 영역이 서로 다른 최종 사용자 참여자가 공통 표현에서 실행되는 여러 가지 툴들을 이용해야 하는 장소인 것을 주장하였다. CAD, 시뮬레이션, 그리고 문서 응용에서 공통 표현의 부재는 큰 결점으로 보인다. 이 영역들에서 데이터베이스를 거친 정보교환을 위한 지원들은 현재 기술에 우선하여 동기화, 일관성, 회복, 버전화, 그리고 보안과 같은 특징들을 자동적으로 제공할 것이다. 또한 이러한 접근은 DBMS들의 스키마들을 통해 표현된 보다 많은 복잡한 데이터 사전 시스템으로 자연스럽게 이끌 것이다.

[Top]
No.
제목
작성자
작성일
조회
1282Oracle 10g vs PostgreSQL 8 vs MySQL 5
정재익
2006-12-16
13124
949Future Directions in DBMS Research
정재익
2004-03-25
14657
873An introduction to object prevalence
정재익
2003-10-30
20956
86325 가지 SQL 작성법
정재익
2003-10-22
21331
862정규화와 Database 모델링
정재익
2003-10-22
23139
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.050초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다