close
본문으로 이동

데이터베이스

위키백과, 우리 모두의 백과사전.
(데이터 베이스에서 넘어옴)
Image
SQL 선택문과 그 결과

데이터베이스(영어: database, DB)는 컴퓨팅에서 데이터의 체계적인 집합이며, 데이터의 수집 및 분석을 위해 최종 사용자, 응용 소프트웨어, 그리고 데이터베이스 자체와 상호작용하는 소프트웨어인 데이터베이스 관리 시스템(DBMS)의 사용을 기반으로 하는 데이터 스토어의 일종이다. DBMS는 추가적으로 데이터베이스를 관리하기 위해 제공되는 핵심 기능들을 포함한다. 데이터베이스, DBMS 및 관련 애플리케이션의 총합을 데이터베이스 시스템이라고 부를 수 있다. 종종 "데이터베이스"라는 용어는 DBMS, 데이터베이스 시스템 또는 데이터베이스와 관련된 애플리케이션 중 어느 하나를 느슨하게 지칭하는 데 사용되기도 한다.

데이터의 디지털 저장 및 검색이 보편화되기 전에는 다양한 애플리케이션과 환경의 데이터 스토리지를 위해 색인 카드가 사용되었다. 가정에서는 요리법, 쇼핑 목록, 연락처 정보 및 기타 정리 데이터를 기록하고 저장하는 데 사용되었고, 비즈니스에서는 발표 메모, 프로젝트 연구 및 메모, 연락처 정보를 기록하는 데, 학교에서는 플래시 카드나 기타 시각 보조 도구로, 학술 연구에서는 서지 인용이나 메모를 카드 파일에 담아두는 데 사용되었다. 전문 서적 색인 작성자들은 1980년대와 1990년대에 색인 소프트웨어로 대체될 때까지 책 색인을 만드는 데 색인 카드를 사용했다.

소규모 데이터베이스는 파일 시스템에 저장될 수 있는 반면, 대규모 데이터베이스는 컴퓨터 클러스터나 클라우드 스토리지에 호스팅된다. 데이터베이스 설계는 데이터 모델링, 효율적인 데이터 표현 및 저장, 질의 언어, 민감한 데이터의 데이터베이스 보안 및 정보 프라이버시, 그리고 병행 액세스 및 장애 허용 시스템 지원을 포함한 분산 컴퓨팅 문제와 같은 형식적 기술과 실무적 고려 사항을 아우른다.

컴퓨터 과학자들은 지원하는 데이터베이스 모델에 따라 데이터베이스 관리 시스템을 분류하기도 한다. 1980년대에는 관계형 데이터베이스가 지배적이 되었다. 이들은 데이터를 일련의 테이블 내의 행과 열로 모델링하며, 대다수가 데이터 작성 및 질의를 위해 SQL을 사용한다. 2000년대에는 서로 다른 질의 언어를 사용한다는 점에서 통칭 NoSQL이라 불리는 비관계형 데이터베이스가 대중화되었다.

용어 및 개요

[편집]

형식적으로 "데이터베이스"란 사용자가 하나 이상의 데이터베이스와 상호작용할 수 있게 하고 데이터베이스에 포함된 모든 데이터에 대한 액세스를 제공하는 컴퓨터 소프트웨어의 통합 집합인 "데이터베이스 관리 시스템"(DBMS)을 통해 액세스되는 관련 데이터의 집합을 의미한다(특정 데이터에 대한 액세스를 제한하는 제약이 존재할 수 있음). DBMS는 대량의 정보를 입력, 저장 및 검색할 수 있는 다양한 기능을 제공하며, 해당 정보가 조직되는 방식을 관리하는 방법을 제공한다.

이들 사이의 밀접한 관계 때문에 "데이터베이스"라는 용어는 데이터베이스와 이를 조작하는 데 사용되는 DBMS 모두를 캐주얼하게 지칭하는 데 자주 사용된다.

전문적인 정보기술 분야 밖에서 데이터베이스라는 용어는 종종 크기 및 사용 요구 사항으로 인해 일반적으로 데이터베이스 관리 시스템의 사용이 필요한 관련 데이터의 모든 컬럼(예: 스프레드시트 또는 카드 색인)을 지칭하는 데 사용된다.[1]

기존의 DBMS는 네 가지 주요 기능 그룹으로 분류할 수 있는 데이터베이스 및 데이터 관리 기능을 제공한다.

  • 데이터 정의 – 데이터가 조직되는 방식의 세부 사항을 정의하는 정의의 생성, 수정 및 제거.
  • 업데이트 – 데이터 자체의 삽입, 수정 및 삭제.[2]
  • 검색 – 특정 기준(예: 질의, 계층 구조 내의 위치 또는 다른 데이터와의 관계적 위치)에 따라 데이터를 선택하고, 해당 데이터를 사용자에게 직접 제공하거나 데이터베이스 자체 또는 다른 애플리케이션에 의한 추가 처리가 가능하도록 만드는 것. 검색된 데이터는 데이터베이스에 저장된 그대로의 수정되지 않은 형태이거나, 데이터베이스의 기존 데이터와 결합하거나 변경하여 얻은 새로운 형태로 제공될 수 있다.[3]
  • 관리 – 사용자 등록 및 모니터링, 데이터 보안 강화, 성능 모니터링, 데이터 무결성 유지, 동시성 제어 처리, 예상치 못한 시스템 장애와 같은 이벤트로 인해 손상된 정보 복구.[4]

데이터베이스와 그 DBMS는 모두 특정 데이터베이스 모델의 원칙을 따른다.[5] "데이터베이스 시스템"은 데이터베이스 모델, 데이터베이스 관리 시스템 및 데이터베이스를 총칭한다.[6]

물리적으로 데이터베이스 서버는 실제 데이터베이스를 보유하고 DBMS 및 관련 소프트웨어만 실행하는 전용 컴퓨터이다. 데이터베이스 서버는 일반적으로 안정적인 저장을 위해 넉넉한 메모리와 RAID 디스크 어레이를 사용하는 다중 처리 컴퓨터이다. 고속 채널을 통해 하나 이상의 서버에 연결된 하드웨어 데이터베이스 가속기도 대량의 트랜잭션 처리 환경에서 사용된다. DBMS는 대부분의 데이터베이스 애플리케이션의 핵심에 위치한다. DBMS는 네트워킹 지원 기능이 내장된 맞춤형 멀티태스킹 커널을 중심으로 구축될 수 있지만, 현대의 DBMS는 일반적으로 이러한 기능을 제공하기 위해 표준 운영체제에 의존한다.

DBMS가 중요한 시장을 형성함에 따라 컴퓨터 및 스토리지 벤더들은 종종 자체 개발 계획에 DBMS 요구 사항을 고려한다.[7]

데이터베이스와 DBMS는 지원하는 데이터베이스 모델(예: 관계형 또는 XML), 실행되는 컴퓨터 유형(서버 클러스터부터 휴대 전화까지), 데이터베이스 액세스에 사용되는 질의 언어(예: SQL 또는 XQuery), 그리고 성능, 확장성, 복원력 및 보안에 영향을 미치는 내부 엔지니어링에 따라 분류될 수 있다.

역사

[편집]

데이터베이스와 각각의 DBMS의 크기, 기능 및 성능은 수십 배로 성장했다. 이러한 성능 향상은 프로세서, 컴퓨터 메모리, 컴퓨터 스토리지 및 컴퓨터 네트워크 분야의 기술 진보에 의해 가능해졌다. 데이터베이스의 개념은 1960년대 중반에 널리 보급된 자기 디스크와 같은 직접 액세스 저장 매체의 등장으로 가능해졌으며, 이전 시스템은 자기 테이프에 데이터를 순차적으로 저장하는 방식에 의존했다. 이후의 데이터베이스 기술 발전은 데이터 모델이나 구조에 따라 세 시대로 나눌 수 있다: 내비게이셔널,[8] SQL/관계형, 그리고 포스트 관계형.

초기의 두 가지 주요 내비게이셔널 데이터 모델은 계층형 모델과 CODASYL 모델(네트워크 모델)이었다. 이들은 한 레코드에서 다른 레코드로의 관계를 따라가기 위해 포인터(종종 물리적 디스크 주소)를 사용하는 것이 특징이었다.

1970년 에드거 F. 코드에 의해 처음 제안된 관계형 모델은 응용 소프트웨어가 링크를 따라가는 대신 콘텐츠로 데이터를 검색해야 한다고 주장함으로써 이러한 전통에서 벗어났다. 관계형 모델은 장부 스타일의 테이블 세트를 사용하며, 각 테이블은 서로 다른 유형의 엔티티에 사용된다. 1980년대 중반에 이르러서야 컴퓨팅 하드웨어가 관계형 시스템(DBMS 및 애플리케이션)의 광범위한 배포를 허용할 만큼 강력해졌다. 그러나 1990년대 초까지 관계형 시스템은 모든 대규모 데이터 처리 애플리케이션에서 지배적이 되었으며, 2018 년 기준 현재까지도 지배적인 위치를 유지하고 있다. IBM DB2, 오라클, MySQL 및 마이크로소프트 SQL 서버가 가장 많이 검색되는 DBMS이다.[9] 관계형 모델을 위해 표준화된 SQL은 지배적인 데이터베이스 언어로서 다른 데이터 모델을 위한 데이터베이스 언어에도 영향을 미쳤다.

객체 지향 데이터베이스는 객체 관계 임피던스 불일치의 불편함을 극복하기 위해 1980년대에 개발되었으며, 이는 "포스트 관계형"이라는 용어의 탄생과 하이브리드 객체 관계 데이터베이스의 개발로 이어졌다.

2000년대 후반의 차세대 포스트 관계형 데이터베이스는 NoSQL 데이터베이스로 알려지게 되었으며, 빠른 키-값 스토어와 문서 지향 데이터베이스를 도입했다. NewSQL 데이터베이스로 알려진 경쟁 "차세대"는 관계형/SQL 모델을 유지하면서 상용 관계형 DBMS에 비해 NoSQL의 높은 성능을 맞추는 것을 목표로 하는 새로운 구현을 시도했다.

1960년대, 내비게이셔널 DBMS

[편집]
Image
내비게이셔널 CODASYL 데이터베이스 모델의 기본 구조

데이터베이스라는 용어의 도입은 1960년대 중반 이후 직접 액세스 스토리지(디스크 및 드럼)의 가용성과 시기적으로 일치했다. 이 용어는 과거의 테이프 기반 시스템과 대비되는 개념으로, 일일 일괄 처리 대신 공유된 대화형 사용을 가능하게 함을 의미했다. 옥스포드 영어사전은 1962년 캘리포니아의 시스템 디밸롭먼트 코퍼레이션 보고서를 특정 기술적 의미에서 "data-base"라는 용어를 사용한 최초의 사례로 인용한다.[10]

컴퓨터의 속도와 기능이 향상됨에 따라 여러 범용 데이터베이스 시스템이 등장했으며, 1960년대 중반까지 이러한 시스템 중 일부가 상업적으로 사용되었다. 표준에 대한 관심이 커지기 시작했고, 그러한 제품 중 하나인 Integrated Data Store(IDS)의 저자인 찰스 바크먼은 코볼의 생성 및 표준화를 담당하는 그룹인 CODASYL 내에 데이터베이스 태스크 그룹을 설립했다. 1971년 데이터베이스 태스크 그룹은 일반적으로 CODASYL 접근 방식으로 알려진 표준을 발표했으며, 곧 이 접근 방식을 기반으로 한 여러 상업용 제품이 시장에 출시되었다.

CODASYL 접근 방식은 애플리케이션에 거대한 네트워크로 형성된 링크된 데이터 집합을 돌아다닐 수 있는 기능을 제공했다. 애플리케이션은 다음 세 가지 방법 중 하나로 레코드를 찾을 수 있었다:

  1. 기본 키(CALC 키로 알려짐, 일반적으로 해시 함수에 의해 구현됨)의 사용
  2. 한 레코드에서 다른 레코드로 관계(세트라고 함)를 따라 이동
  3. 순차적인 순서로 모든 레코드를 스캔

이후 시스템들은 대체 액세스 경로를 제공하기 위해 B 트리를 추가했다. 많은 CODASYL 데이터베이스는 (내비게이셔널 API와는 구별되는) 최종 사용자를 위한 선언적 질의 언어도 추가했다. 그러나 CODASYL 데이터베이스는 복잡했으며 유용한 애플리케이션을 제작하기 위해 상당한 교육과 노력이 필요했다.

IBM 또한 1966년에 정보 관리 시스템(Information Management System, IMS)으로 알려진 자체 DBMS를 보유하고 있었다. IMS는 아폴로 계획을 위해 시스템/360상에서 작성된 소프트웨어의 발전된 형태였다. IMS는 개념적으로 CODASYL과 유사했으나, 데이터 내비게이션 모델로 CODASYL의 네트워크 모델 대신 엄격한 계층 구조를 사용했다. 두 개념 모두 데이터에 액세스하는 방식 때문에 나중에 내비게이셔널 데이터베이스로 알려지게 되었다. 이 용어는 바크먼의 1973년 튜링상 강연인 '항해자로서의 프로그래머(The Programmer as Navigator)'에 의해 대중화되었다. IMS는 IBM에 의해 계층형 데이터베이스로 분류된다. IDMS와 Cincom Systems의 TOTAL 데이터베이스는 네트워크 데이터베이스로 분류된다. IMS는 2014 년 기준 현재까지도 사용되고 있다.[11]

1970년대, 관계형 DBMS

[편집]

에드거 F. 코드는 산호세 (캘리포니아주)에 있는 IBM 사무실에서 주로 하드 디스크 시스템 개발에 참여하며 근무했다.[12] 그는 CODASYL 접근 방식의 내비게이셔널 모델, 특히 "검색" 기능의 부재에 불만을 느꼈다. 1970년에 그는 데이터베이스 구축에 대한 새로운 접근 방식을 개략적으로 설명하는 여러 논문을 썼으며, 이는 결국 획기적인 논문인 '대규모 공유 데이터 뱅크를 위한 데이터 관계 모델(A Relational Model of Data for Large Shared Data Banks)'로 정점에 달했다.[13]

이 논문은 대규모 데이터베이스를 저장하고 작업하기 위한 새로운 시스템을 설명했다. CODASYL에서처럼 레코드를 일종의 자유 형식 레코드의 연결 리스트에 저장하는 대신, 코드의 아이디어는 데이터를 여러 "테이블"로 구성하는 것이었으며, 각 테이블은 서로 다른 유형의 엔티티에 사용된다. 각 테이블은 엔티티의 속성을 포함하는 고정된 수의 컬럼을 갖는다. 각 테이블의 하나 이상의 컬럼은 테이블의 로우를 고유하게 식별할 수 있는 기본 키로 지정되었다. 테이블 간의 상호 참조는 디스크 주소가 아닌 항상 이러한 기본 키를 사용했으며, 질의는 (모델의 이름이 유래된) 관계 논리의 수학적 시스템에 기반한 일련의 연산을 사용하여 이러한 키 관계를 바탕으로 테이블을 조인한다. 데이터를 정규화된 테이블(또는 관계) 세트로 분할하는 것은 각 "사실"이 한 번만 저장되도록 보장하여 업데이트 연산을 단순화하는 것을 목표로 했다. 뷰(view)라고 불리는 가상 테이블은 서로 다른 사용자에게 서로 다른 방식으로 데이터를 제시할 수 있었지만, 뷰를 직접 업데이트할 수는 없었다.

코드는 모델을 정의하기 위해 테이블, 로우, 컬럼 대신 관계(relation), 튜플(tuple), 도메인(domain)이라는 수학적 용어를 사용했다. 현재 익숙한 용어들은 초기 구현에서 비롯되었다. 코드는 나중에 실제 구현들이 모델의 기반이 된 수학적 토대에서 벗어나는 경향을 비판하기도 했다.

Image
관계형 모델에서 레코드는 데이터베이스에 저장되지 않고 레코드에 포함된 데이터 간에 필요에 따라 정의되는 가상 키를 사용하여 "연결"된다.

디스크 주소가 아닌 기본 키(사용자 중심 식별자)를 사용하여 테이블 간 관계를 표현하는 것에는 두 가지 주요 동기가 있었다. 엔지니어링 관점에서는 값비싼 데이터베이스 재조직 없이도 테이블을 재배치하고 크기를 조정할 수 있게 해주었다. 하지만 코드는 의미론의 차이에 더 관심이 있었다. 명시적인 식별자를 사용하는 것은 깨끗한 수학적 정의를 가진 업데이트 연산을 정의하기 쉽게 만들었고, 또한 확립된 규율인 1차 술어 논리의 관점에서 질의 연산을 정의할 수 있게 했다. 이러한 연산은 깨끗한 수학적 특성을 가지기 때문에 질의를 증명 가능한 올바른 방식으로 다시 쓰는 것이 가능해지며, 이것이 질의 최적화의 기초가 된다. 테이블 간의 연결이 더 이상 명시적이지 않더라도 계층형 또는 네트워크 모델에 비해 표현력의 손실은 없다.

계층형 및 네트워크 모델에서 레코드는 복잡한 내부 구조를 가질 수 있었다. 예를 들어 직원의 급여 이력은 직원 레코드 내에서 "반복 그룹"으로 표현될 수 있었다. 관계형 모델에서 정규화 과정은 이러한 내부 구조를 논리적 키로만 연결된 여러 테이블에 보관된 데이터로 대체하게 했다.

예를 들어, 데이터베이스 시스템의 일반적인 용도는 사용자에 대한 정보, 이름, 로그인 정보, 다양한 주소 및 전화번호를 추적하는 것이다. 내비게이셔널 접근 방식에서는 이 모든 데이터가 단일 가변 길이 레코드에 배치된다. 관계형 접근 방식에서는 데이터가 (예를 들어) 사용자 테이블, 주소 테이블 및 전화번호 테이블로 정규화된다. 주소나 전화번호가 실제로 제공된 경우에만 이러한 선택적 테이블에 레코드가 생성된다.

디스크 주소 대신 논리적 식별자를 사용하여 로우/레코드를 식별하는 것 외에도, 코드는 애플리케이션이 여러 레코드에서 데이터를 조합하는 방식을 변경했다. 애플리케이션이 링크를 따라가며 한 번에 한 레코드씩 데이터를 수집하도록 요구하는 대신, 데이터를 찾기 위한 액세스 경로가 아니라 어떤 데이터가 필요한지를 표현하는 선언적 질의 언어를 사용하게 했다. 데이터에 대한 효율적인 액세스 경로를 찾는 것은 애플리케이션 프로그래머가 아닌 데이터베이스 관리 시스템의 책임이 되었다. 질의 최적화라고 불리는 이 과정은 질의가 수리 논리의 관점에서 표현된다는 사실에 의존했다.

코드의 논리는 캘리포니아 대학교 버클리[12]의 유진 웡과 마이클 스톤브레이커가 이끄는 팀을 포함하여 여러 대학의 팀들이 이 주제를 연구하도록 영감을 주었다. 이들은 이미 지리 데이터베이스 프로젝트를 위해 할당된 자금과 학생 프로그래머들을 사용하여 코드를 작성하며 INGRES를 시작했다. 1973년에 시작된 INGRES는 1979년에 널리 사용될 수 있는 수준의 첫 번째 테스트 제품을 인도했다. INGRES는 QUEL로 알려진 데이터 액세스용 "언어" 사용을 포함하여 여러 면에서 시스템 R과 유사했다. 시간이 흐르면서 INGRES는 부상하는 SQL 표준으로 이동했다.

IBM 자체적으로도 관계형 모델의 테스트 구현인 PRTV와 생산용 구현인 비즈니스 시스템 12를 수행했으나 현재는 모두 중단되었다. 허니웰은 멀틱스용으로 MRDS(Multics Relational Data Store)를 작성했고, 현재는 두 가지 새로운 구현인 Alphora Dataphor와 Rel이 있다. 관계형이라고 불리는 대부분의 다른 DBMS 구현은 실제로는 SQL DBMS이다.

1974년, 미시간 대학교는 D.L. 차일즈의 집합론적 데이터 모델에 기반하여 MICRO 정보 관리 시스템[14] 개발을 시작했다.[15][16][17] 대학은 1974년에 코드와 바크먼 사이의 토론을 주최했는데, IBM의 브루스 린제이는 이를 후에 "서로에게 번개를 던지는 것 같았다!"라고 묘사했다.[12] MICRO는 미국 노동부, 미국 환경 보호국, 그리고 앨버타 대학교, 미시간 대학교, 웨인 주립 대학교의 연구원들에 의해 매우 큰 데이터 집합을 관리하는 데 사용되었다. 이는 미시간 터미널 시스템을 사용하는 IBM 메인프레임 컴퓨터에서 실행되었다.[18] 이 시스템은 1998년까지 가동되었다.

통합 접근 방식

[편집]

1970년대와 1980년대에는 통합된 하드웨어와 소프트웨어로 데이터베이스 시스템을 구축하려는 시도가 있었다. 그 기저의 철학은 이러한 통합이 낮은 비용으로 더 높은 성능을 제공할 것이라는 점이었다. 사례로는 IBM 시스템/38, 테라데이터의 초기 제품, 그리고 브리튼 리(Britton Lee, Inc.)의 데이터베이스 머신이 있었다.

데이터베이스 관리를 위한 하드웨어 지원의 또 다른 접근 방식은 ICL(International Computers Limited)의 CAFS(Content Addressable File Store) 가속기로, 프로그래밍 가능한 검색 기능을 갖춘 하드웨어 디스크 컨트롤러였다. 장기적으로 볼 때 전문화된 데이터베이스 머신은 범용 컴퓨터의 빠른 개발과 진보 속도를 따라갈 수 없었기 때문에 이러한 노력들은 대체로 성공하지 못했다. 따라서 오늘날 대부분의 데이터베이스 시스템은 범용 하드웨어에서 실행되고 범용 컴퓨터 데이터 스토리지를 사용하는 소프트웨어 시스템이다. 그러나 이러한 아이디어는 Netezza나 오라클(Exadata)과 같은 일부 회사에 의해 특정 애플리케이션에서 여전히 추구되고 있다.

1970년대 후반, SQL DBMS

[편집]

IBM은 사내의 반대에도 불구하고 코드의 주도하에 프로토타입 시스템인 시스템 R 작업을 시작한 팀을 구성했다.[12] 첫 번째 버전은 1974/5년에 준비되었으며, 이어 데이터가 분할되어 레코드의 모든 데이터(그중 일부는 선택적임)를 단일한 큰 "덩어리"에 저장할 필요가 없도록 하는 다중 테이블 시스템 작업이 시작되었다. 이후 다중 사용자 버전이 1978년과 1979년에 고객들에 의해 테스트되었으며, 이때 표준화된 질의 언어인 SQL이 추가되었다. 코드의 아이디어는 실행 가능할 뿐만 아니라 CODASYL보다 우수함을 입증하며 IBM이 SQL/DS로 알려진 시스템 R의 진정한 생산 버전을 개발하도록 밀어붙였고, 이는 나중에 Database 2(IBM DB2)가 되었다.

래리 엘리슨의 오라클 데이터베이스(또는 간단히 오라클)는 시스템 R에 대한 IBM의 논문을 바탕으로 다른 체인에서 시작되었다. 오라클 V1 구현은 1978년에 완료되었으나, 엘리슨이 1979년에 IBM보다 먼저 시장에 출시한 것은 오라클 버전 2였다.[19]

스톤브레이커는 INGRES의 교훈을 적용하여 현재 PostgreSQL로 알려진 새로운 데이터베이스 Postgres를 개발했다. PostgreSQL은 종종 글로벌 미션 크리티컬 애플리케이션에 사용된다(.org 및 .info 도메인 네임 레지스트리는 많은 대기업 및 금융 기관과 마찬가지로 이를 기본 데이터 스토어로 사용한다).

스웨덴에서도 코드의 논문이 읽혔고 1970년대 중반 웁살라 대학교에서 Mimer SQL이 개발되었다. 1984년에 이 프로젝트는 독립 기업으로 통합되었다.

또 다른 데이터 모델인 개체-관계 모델은 1976년에 등장했으며, 초기 관계형 모델보다 더 친숙한 설명을 강조했기 때문에 데이터베이스 설계에서 인기를 얻었다. 나중에 개체-관계 구조는 관계형 모델을 위한 데이터 모델링 구조로 보강되었으며, 두 모델 간의 차이는 무의미해졌다.

1980년대, 데스크톱에서

[편집]

IBM 및 사이베이스, 인포믹스(Informix Corporation)와 같은 다양한 소프트웨어 회사들 외에도, 1980년대까지 대부분의 대형 컴퓨터 하드웨어 벤더들은 DEC의 VAX Rdb/VMS와 같은 자체 데이터베이스 시스템을 보유하고 있었다.[20] 이 10년은 데스크톱 컴퓨팅의 시대를 열었다. 새로운 컴퓨터들은 로터스 1-2-3와 같은 스프레드시트와 dBASE와 같은 데이터베이스 소프트웨어로 사용자들에게 권한을 부여했다. dBASE 제품은 가볍고 컴퓨터 사용자라면 누구나 즉시 이해하기 쉬웠다. dBASE의 제작자인 C. 웨인 랫리프는 다음과 같이 말했다: "dBASE는 이미 많은 번거로운 작업이 완료되어 있었다는 점에서 BASIC, C, FORTRAN, COBOL과 같은 프로그램들과 달랐다. 데이터 조작은 사용자가 아닌 dBASE에 의해 수행되므로 사용자는 파일 열기, 읽기, 닫기 및 공간 할당 관리와 같은 지저분한 세부 사항을 신경 쓰는 대신 자신이 하고 있는 일에 집중할 수 있다."[21] dBASE는 1980년대와 1990년대 초반에 가장 많이 팔린 소프트웨어 타이틀 중 하나였다.

1990년대, 객체 지향

[편집]

1990년대 초반까지 데이터베이스는 약 10년 만에 10억 달러 규모의 산업이 되었다.[20] 1990년대에는 객체 지향 프로그래밍의 부상과 함께 다양한 데이터베이스의 데이터가 처리되는 방식이 성장했다. 프로그래머와 설계자는 데이터베이스의 데이터를 객체로 취급하기 시작했다. 즉, 어떤 사람의 데이터가 데이터베이스에 있다면, 그 사람의 주소, 전화번호, 나이와 같은 속성들은 이제 부수적인 데이터가 아니라 그 사람에게 속한 것으로 간주되었다. 이를 통해 데이터 간의 관계가 개별 필드가 아닌 객체와 그 속성에 연결될 수 있게 되었다.[22] "객체 관계 임피던스 불일치"라는 용어는 프로그래밍된 객체와 데이터베이스 테이블 간의 변환 시 발생하는 불편함을 설명했다. 객체 지향 데이터베이스와 객체 관계 데이터베이스는 프로그래머가 순수 관계형 SQL의 대안으로 사용할 수 있는 객체 지향 언어(때로는 SQL의 확장으로서)를 제공함으로써 이 문제를 해결하려고 시도한다. 프로그래밍 측면에서는 객체 관계 매핑(ORM)으로 알려진 라이브러리들이 동일한 문제를 해결하려고 시도한다.

2000년대, NoSQL 및 NewSQL

[편집]

데이터베이스 판매는 닷컴 버블 기간과 그 이후 전자 상거래의 부상으로 급격히 성장했다. MySQL과 같은 오픈 소스 데이터베이스의 인기는 2000년 이후 크게 성장하여, 2005년에 오라클의 켄 제이콥스는 "이 친구들이 과거에 우리가 IBM에 했던 짓을 우리에게 하고 있을지도 모른다"라고 말할 정도였다.[20]

XML 데이터베이스는 XML 문서 속성을 기반으로 질의를 허용하는 구조화된 문서 지향 데이터베이스의 일종이다. XML 데이터베이스는 주로 데이터가 과학 기사, 특허, 세금 신고 및 인사 기록과 같이 유연하거나 매우 엄격한 구조를 가진 문서 모음으로 간주되는 애플리케이션에서 사용된다.

NoSQL 데이터베이스는 종종 매우 빠르고,[23][24] 고정된 테이블 스키마가 필요 없으며, 역정규화된 데이터를 저장하여 조인 연산을 피하고, 수평적 확장이 가능하도록 설계되었다.

최근 몇 년 동안 높은 파티션 허용 오차를 가진 대규모 분산 데이터베이스에 대한 강력한 요구가 있었으나, CAP 정리에 따르면 분산 시스템이 일관성, 가용성 및 파티션 허용 오차 보장을 동시에 제공하는 것은 불가능하다. 분산 시스템은 이 보장 중 두 가지를 동시에 만족시킬 수 있지만 세 가지 모두는 불가능하다. 그 때문에 많은 NoSQL 데이터베이스는 데이터 일관성 수준을 낮추는 대신 가용성과 파티션 허용 오차 보장을 모두 제공하기 위해 소위 궁극적 일관성을 사용하고 있다.

NewSQL은 전통적인 데이터베이스 시스템의 ACID 보장을 유지하고 SQL을 계속 사용하면서도 온라인 트랜잭션 처리(읽기-쓰기) 워크로드에 대해 NoSQL 시스템과 동일한 확장 가능한 성능을 제공하는 것을 목표로 하는 현대적 관계형 데이터베이스의 한 부류이다.

사용 사례

[편집]

데이터베이스는 조직의 내부 운영을 지원하고 고객 및 공급업체와의 온라인 상호작용을 뒷받침하는 데 사용된다(전사적 소프트웨어 참조).

데이터베이스는 관리 정보뿐만 아니라 엔지니어링 데이터나 경제 모델과 같은 보다 전문화된 데이터를 보유하는 데 사용된다. 사례로는 컴퓨터화된 도서관 시스템, 비행 예약 시스템, 컴퓨터화된 부품 재고 시스템, 그리고 웹페이지 모음을 데이터베이스에 저장하는 많은 저작물 관리 시스템 등이 있다.

분류

[편집]

데이터베이스를 분류하는 한 가지 방법은 콘텐츠의 유형에 따른 것이다. 예를 들어, 서지 데이터베이스, 문서-텍스트, 통계 또는 멀티미디어 객체 등이 있다. 또 다른 방법은 응용 분야에 따른 것으로, 예를 들어 회계, 음악 작곡, 영화, 은행, 제조 또는 보험 등이 있다. 세 번째 방법은 데이터베이스 구조나 인터페이스 유형과 같은 기술적 측면에 따른 것이다. 이 섹션은 다양한 종류의 데이터베이스를 특징짓는 데 사용되는 몇 가지 형용사를 나열한다.

  • 인메모리 데이터베이스는 주로 주기억장치에 상주하지만, 일반적으로 비휘발성 컴퓨터 데이터 스토리지에 의해 백업되는 데이터베이스이다. 메인 메모리 데이터베이스는 디스크 데이터베이스보다 빠르기 때문에 텔레콤 네트워크 장비와 같이 응답 시간이 중요한 곳에서 자주 사용된다.
  • 액티브 데이터베이스는 데이터베이스 내외부의 조건에 반응할 수 있는 이벤트 중심 아키텍처를 포함한다. 가능한 용도로는 보안 모니터링, 알림, 통계 수집 및 권한 부여 등이 있다. 많은 데이터베이스가 데이터베이스 트리거의 형태로 액티브 데이터베이스 기능을 제공한다.
  • 클라우드 데이터베이스는 클라우드 기술에 의존한다. 데이터베이스와 대부분의 DBMS가 원격인 "클라우드"에 상주하며, 애플리케이션은 프로그래머에 의해 개발되고 나중에 웹 브라우저 및 오픈 API를 통해 최종 사용자에 의해 유지보수 및 사용된다.
  • 데이터 웨어하우스는 운영 데이터베이스와 종종 시장 조사 기관과 같은 외부 소스에서 데이터를 보관한다. 웨어하우스는 운영 데이터에 액세스할 수 없는 관리자 및 기타 최종 사용자가 사용할 수 있는 중앙 데이터 소스가 된다. 예를 들어 판매 데이터는 주간 합계로 집계되고 내부 제품 코드에서 UPC를 사용하도록 변환되어 ACNielsen 데이터와 비교될 수 있다. 데이터 웨어하우징의 일부 기본적이고 필수적인 구성 요소에는 데이터를 추출, 분석 및 마이닝하고, 데이터를 변환, 적재 및 관리하여 추가 사용이 가능하도록 만드는 작업이 포함된다.
  • 연역적 데이터베이스는 논리형 프로그래밍을 관계형 데이터베이스와 결합한다.
  • 분산 데이터베이스는 데이터와 DBMS가 모두 여러 컴퓨터에 걸쳐 있는 데이터베이스이다.
  • 문서 지향 데이터베이스는 문서 지향 정보 또는 반구조화된 정보를 저장, 검색 및 관리하기 위해 설계되었다. 문서 지향 데이터베이스는 NoSQL 데이터베이스의 주요 범주 중 하나이다.
  • 임베디드 데이터베이스 시스템은 DBMS가 응용 소프트웨어와 밀접하게 통합되어 DBMS가 애플리케이션의 최종 사용자에게 숨겨지고 지속적인 유지보수가 거의 또는 전혀 필요하지 않은 방식으로 저장된 데이터에 액세스해야 하는 DBMS이다.[25]
  • 최종 사용자 데이터베이스는 개별 최종 사용자에 의해 개발된 데이터로 구성된다. 이러한 사례로는 문서 모음, 스프레드시트, 프레젠테이션, 멀티미디어 및 기타 파일 등이 있다. 이러한 데이터베이스를 지원하기 위해 여러 제품이 존재한다.
  • 연합 데이터베이스 시스템은 각각 자체 DBMS를 가진 여러 개의 구별된 데이터베이스로 구성된다. 이는 여러 자율적 DBMS(서로 다른 유형일 수도 있으며, 이 경우 이종 데이터베이스 시스템이 됨)를 투명하게 통합하고 통합된 개념적 뷰를 제공하는 연합 데이터베이스 관리 시스템(FDBMS)에 의해 단일 데이터베이스처럼 처리된다.
  • 때로는 다중 데이터베이스(multi-database)라는 용어가 연합 데이터베이스의 동의어로 사용되기도 하지만, 단일 애플리케이션에서 협력하는 덜 통합된(예: FDBMS와 관리되는 통합 스키마가 없는) 데이터베이스 그룹을 의미할 수도 있다. 이 경우 일반적으로 배포를 위해 미들웨어가 사용되며, 이는 참여하는 데이터베이스 간에 분산 트랜잭션을 허용하기 위해 2단계 커밋 프로토콜과 같은 원자적 커밋 프로토콜(ACP)을 포함한다.
  • 그래프 데이터베이스는 정보를 표현하고 저장하기 위해 노드, 에지 및 프로퍼티를 가진 그래프 구조를 사용하는 NoSQL 데이터베이스의 일종이다. 모든 그래프를 저장할 수 있는 일반 그래프 데이터베이스는 트리플스토어나 네트워크 데이터베이스와 같은 전문화된 그래프 데이터베이스와는 구별된다.
  • 어레이 DBMS는 위성 이미지나 기후 시뮬레이션 출력과 같은 (보통 대규모) 다차원 배열의 모델링, 저장 및 검색을 가능하게 하는 NoSQL DBMS의 일종이다.
  • 하이퍼텍스트 또는 하이퍼미디어 데이터베이스에서 객체를 나타내는 단어나 텍스트 조각(예: 다른 텍스트 조각, 기사, 사진 또는 영화)은 해당 객체에 하이퍼링크로 연결될 수 있다. 하이퍼텍스트 데이터베이스는 방대한 양의 이질적인 정보를 정리하는 데 특히 유용하다. 예를 들어, 사용자가 텍스트 여기저기를 편리하게 이동할 수 있는 온라인 백과사전을 정리하는 데 유용하다. 따라서 월드 와이드 웹은 거대한 분산 하이퍼텍스트 데이터베이스이다.
  • 지식 베이스(줄여서 KB, kb 또는 Δ[26][27])는 지식 경영을 위한 특별한 종류의 데이터베이스로, 지식의 컴퓨터화된 수집, 조직 및 정보 검색을 위한 수단을 제공한다. 또한 문제와 그 해결책 및 관련 경험을 나타내는 데이터 모음이기도 하다.
  • 모바일 데이터베이스는 모바일 컴퓨팅 장치에서 휴대하거나 동기화할 수 있다.
  • 운영 데이터베이스는 조직의 운영에 대한 상세 데이터를 저장한다. 이들은 일반적으로 트랜잭션을 사용하여 상대적으로 많은 양의 업데이트를 처리한다. 사례로는 비즈니스 고객의 연락처, 신용 및 인구통계 정보를 기록하는 고객 데이터베이스, 직원의 급여, 복리후생, 기술 데이터와 같은 정보를 보유하는 인사 데이터베이스, 제품 구성 요소, 부품 재고에 대한 세부 정보를 기록하는 전사적 자원 관리 시스템, 조직의 자금, 회계 및 금융 거래를 추적하는 재무 데이터베이스 등이 있다.
  • 병렬 데이터베이스는 데이터 로딩, 인덱스 생성 및 질의 평가와 같은 작업을 위해 병렬화를 통해 성능 향상을 꾀한다.
기저의 컴퓨터 하드웨어 아키텍처에 의해 유도되는 주요 병렬 DBMS 아키텍처는 다음과 같다:
  • 공유 메모리 아키텍처: 여러 프로세서가 메인 메모리 공간과 다른 데이터 스토리지를 공유한다.
  • 공유 디스크 아키텍처: 각 처리 유닛(일반적으로 여러 프로세서로 구성됨)은 자체 메인 메모리를 갖지만, 모든 유닛이 다른 스토리지를 공유한다.
  • 무공유 아키텍처: 각 처리 유닛이 자체 메인 메모리와 다른 스토리지를 갖는다.
  • 확률적 데이터베이스는 정밀하지 않은 데이터로부터 추론을 이끌어내기 위해 퍼지 논리를 사용한다.
  • 실시간 데이터베이스는 결과가 즉시 돌아와서 바로 조치될 수 있을 만큼 충분히 빠르게 트랜잭션을 처리한다.
  • 공간 데이터베이스는 다차원적 특징을 가진 데이터를 저장할 수 있다. 이러한 데이터에 대한 질의에는 "내 주변에서 가장 가까운 호텔은 어디인가?"와 같은 위치 기반 질의가 포함된다.
  • 이력 데이터베이스는 이력 데이터 모델 및 SQL의 이력 버전과 같이 시간적 측면이 내장되어 있다. 더 구체적으로 시간적 측면은 일반적으로 유효 시간과 트랜잭션 시간을 포함한다.
  • 용어 지향 데이터베이스는 특정 분야에 맞춰 맞춤화된 객체 지향 데이터베이스를 기반으로 구축된다.
  • 비정형 데이터 데이터베이스는 일반적인 데이터베이스에 자연스럽고 편리하게 들어맞지 않는 다양한 객체들을 관리 가능하고 보호된 방식으로 저장하기 위한 것이다. 여기에는 이메일 메시지, 문서, 저널, 멀티미디어 객체 등이 포함될 수 있다. 일부 객체는 고도로 구조화될 수 있으므로 이 이름은 오해의 소지가 있을 수 있다. 그러나 전체적인 객체 모음은 미리 정의된 구조적 프레임워크에 들어맞지 않는다. 현재 확립된 대부분의 DBMS는 다양한 방식으로 비정형 데이터를 지원하며, 새로운 전용 DBMS도 등장하고 있다.

데이터베이스 관리 시스템

[편집]

코놀리와 베그는 데이터베이스 관리 시스템(DBMS)을 "사용자가 데이터베이스를 정의, 생성, 유지 및 액세스 제어를 할 수 있게 해주는 소프트웨어 시스템"으로 정의한다.[28] DBMS의 사례로는 MySQL, MariaDB, PostgreSQL, 마이크로소프트 SQL 서버, 오라클 데이터베이스 및 마이크로소프트 액세스 등이 있다.

DBMS 약어는 때때로 기저의 데이터베이스 모델을 나타내기 위해 확장되기도 하는데, 관계형 모델의 경우 RDBMS, 객체 (지향) 모델의 경우 OODBMS, 객체 관계 모델의 경우 ORDBMS를 사용한다. 다른 확장으로는 분산 데이터베이스 관리 시스템을 위한 DDBMS와 같이 다른 특성을 나타낼 수도 있다.

DBMS가 제공하는 기능은 매우 다양할 수 있다. 핵심 기능은 데이터의 저장, 검색 및 업데이트이다. 코드는 완전한 범용 DBMS가 제공해야 할 다음과 같은 기능과 서비스를 제안했다:[29]

  • 데이터 저장, 검색 및 업데이트
  • 메타데이터를 설명하는 사용자 액세스 가능 카탈로그 또는 데이터 사전
  • 트랜잭션 및 동시성 지원
  • 데이터베이스 손상 시 복구를 위한 시설
  • 데이터 액세스 및 업데이트 권한 부여 지원
  • 원격 위치에서의 액세스 지원
  • 데이터베이스의 데이터가 특정 규칙을 준수하도록 보장하는 제약 조건 강화

또한 DBMS는 가져오기, 내보내기, 모니터링, 조각 모음 및 분석 유틸리티를 포함하여 데이터베이스를 효과적으로 관리하는 데 필요할 수 있는 일련의 유틸리티를 제공할 것으로 일반적으로 기대된다.[30] 데이터베이스와 애플리케이션 인터페이스 사이에서 상호작용하는 DBMS의 핵심 부분을 때때로 데이터베이스 엔진이라고 부른다.

DBMS는 종종 정적 및 동적으로 튜닝할 수 있는 구성 매개변수를 갖는데, 예를 들어 데이터베이스가 사용할 수 있는 서버의 최대 메인 메모리 양 등이 있다. 추세는 수동 구성의 양을 최소화하는 것이며, 임베디드 데이터베이스와 같은 경우에는 제로 관리를 지향할 필요성이 매우 중요하다.

대형 주요 기업용 DBMS는 크기와 기능이 증가하는 경향이 있으며, 수명 전반에 걸쳐 수천 인년(human years)의 개발 노력이 수반되어 왔다.[a]

초기의 다중 사용자 DBMS는 일반적으로 단말기나 터미널 에뮬레이션 소프트웨어를 통한 액세스를 통해서만 애플리케이션이 동일한 컴퓨터에 상주할 수 있도록 허용했다. 클라이언트-서버 구조는 애플리케이션이 클라이언트 데스크톱에 상주하고 데이터베이스가 서버에 상주하여 처리가 분산될 수 있도록 한 발전된 형태였다. 이는 웹 애플리케이션 서버와 웹 서버를 통합하고 최종 사용자 인터페이스를 웹 브라우저를 통해 제공하며 데이터베이스가 인접 계층에만 직접 연결되는 다층 구조로 진화했다.[32]

범용 DBMS는 공개 애플리케이션 프로그래밍 인터페이스(API)를 제공하며, 선택적으로 데이터베이스와 상호작용하고 조작하기 위한 애플리케이션을 작성할 수 있도록 SQL과 같은 데이터베이스 언어용 프로세서를 제공한다. 특수 목적 DBMS는 비공개 API를 사용할 수 있으며 단일 애플리케이션에 맞게 구체적으로 맞춤화되고 연결될 수 있다. 예를 들어, 전자우편 시스템은 메시지 삽입, 메시지 삭제, 첨부 파일 처리, 차단 목록 조회, 이메일 주소와 메시지 연관 등 범용 DBMS의 많은 기능을 수행하지만, 이러한 기능은 이메일을 처리하는 데 필요한 범위로 제한된다.

애플리케이션

[편집]

데이터베이스와의 외부 상호작용은 DBMS와 인터페이스하는 애플리케이션 프로그램을 통해 이루어진다.[33] 이는 사용자가 텍스트나 그래픽으로 SQL 질의를 실행할 수 있게 해주는 데이터베이스 도구부터, 정보를 저장하고 검색하기 위해 데이터베이스를 사용하는 웹사이트에 이르기까지 다양할 수 있다.

애플리케이션 프로그램 인터페이스

[편집]

프로그래머는 애플리케이션 프로그램 인터페이스(API)를 통하거나 데이터베이스 언어를 통해 데이터베이스(때로는 데이터소스라고 함)에 대한 상호작용을 코딩할 것이다. 선택한 특정 API나 언어는 DBMS에 의해 지원되어야 하며, 이는 전처리기나 브리징 API를 통해 간접적으로 지원될 수도 있다. 일부 API는 데이터베이스 독립적인 것을 목표로 하는데, ODBC가 흔히 알려진 예시이다. 다른 일반적인 API로는 JDBC와 ADO.NET이 있다.

데이터베이스 언어

[편집]

데이터베이스 언어는 특수 목적 언어로, 때로는 하위 언어로 구분되는 다음 작업 중 하나 이상을 가능하게 한다:

  • 데이터 제어 언어(DCL) – 데이터에 대한 액세스를 제어한다.
  • 데이터 정의 언어(DDL) – 테이블 생성, 변경 또는 삭제 및 테이블 간의 관계와 같은 데이터 유형을 정의한다.
  • 데이터 조작 언어(DML) – 데이터 발생 항목의 삽입, 업데이트 또는 삭제와 같은 작업을 수행한다.
  • 질의 언어(DQL) – 정보 검색 및 파생 정보 계산을 가능하게 한다.

데이터베이스 언어는 특정 데이터 모델에 특화되어 있다. 주목할 만한 사례는 다음과 같다:

  • SQL은 데이터 정의, 데이터 조작 및 질의의 역할을 단일 언어로 결합한다. 이는 관계형 모델을 위한 최초의 상업용 언어 중 하나였으나, (예를 들어 테이블의 로우와 컬럼이 순서대로 정렬될 수 있다는 점 등에서) 코드가 설명한 관계형 모델과는 일부 측면에서 차이가 있다. SQL은 1986년에 미국 국가표준 협회(ANSI)의 표준이 되었고, 1987년에 국제 표준화 기구(ISO)의 표준이 되었다. 표준은 이후 정기적으로 향상되었으며 모든 주류 상용 관계형 DBMS에 의해 (다양한 준수 정도로) 지원된다.[34][35]
  • OQL은 (객체 데이터 관리 그룹에 의한) 객체 모델 언어 표준이다. 이는 JDOQL 및 EJB QL과 같은 일부 새로운 질의 언어의 설계에 영향을 미쳤다.
  • XQuery는 MarkLogic 및 eXist와 같은 XML 데이터베이스 시스템, 오라클 및 DB2와 같이 XML 기능을 가진 관계형 데이터베이스, 그리고 Saxon과 같은 인메모리 XML 프로세서에 의해 구현된 표준 XML 질의 언어이다.
  • SQL/XML은 XQuery를 SQL과 결합한다.[36]

데이터베이스 언어는 다음과 같은 기능도 포함할 수 있다:

  • DBMS 전용 구성 및 저장 엔진 관리
  • 카운팅, 합계, 평균, 정렬, 그룹화 및 상호 참조와 같은 질의 결과를 수정하기 위한 계산
  • 제약 조건 강화(예: 자동차 데이터베이스에서 자동차당 하나의 엔진 유형만 허용)
  • 프로그래머의 편의를 위한 질의 언어의 애플리케이션 프로그래밍 인터페이스 버전

스토리지

[편집]

데이터베이스 스토리지는 데이터베이스의 물리적 실체화를 담는 컨테이너이다. 이는 데이터베이스 아키텍처에서 내부(물리) 수준을 구성한다. 또한 필요할 때 내부 수준에서 개념적 수준과 외부 수준을 재구성하는 데 필요한 모든 정보(예: 메타데이터, "데이터에 관한 데이터" 및 내부 자료 구조)를 포함한다. 디지털 객체로서의 데이터베이스는 저장되어야 하는 세 개의 정보 계층, 즉 데이터, 구조, 그리고 의미론을 포함한다. 데이터베이스의 향후 보존 및 수명 연장을 위해 세 계층 모두의 적절한 저장이 필요하다.[37] 데이터를 영구 저장소에 넣는 것은 일반적으로 데이터베이스 엔진(일명 "저장 엔진")의 책임이다. 일반적으로 기저의 운영체제를 통해(그리고 종종 저장 레이아웃을 위한 중간체로 운영체제의 파일 시스템을 사용하여) DBMS가 액세스하지만, 스토리지 속성 및 구성 설정은 DBMS의 효율적인 운영을 위해 매우 중요하므로 데이터베이스 관리자에 의해 밀접하게 관리된다. 운영 중인 DBMS는 항상 여러 유형의 스토리지(예: 메모리 및 외부 저장소)에 상주하는 데이터베이스를 갖는다. 데이터베이스 데이터와 추가로 필요한 정보는 아마도 매우 방대한 양일 것이며 비트로 코딩된다. 데이터는 일반적으로 개념적 수준 및 외부 수준에서 데이터가 보이는 방식과는 완전히 다른 구조로 저장소에 상주하지만, 사용자나 프로그램에 의해 필요할 때 이러한 수준의 재구성을 (가능한 최선으로) 최적화할 뿐만 아니라 데이터로부터 필요한 추가 유형의 정보(예: 데이터베이스 질의 시)를 계산하기 위한 방식으로 처리된다.

일부 DBMS는 데이터를 저장하는 데 어떤 문자 인코딩이 사용되었는지 지정을 지원하므로 동일한 데이터베이스에서 여러 인코딩을 사용할 수 있다.

저장 엔진은 데이터 모델을 직렬화하여 선택한 매체에 기록할 수 있도록 다양한 하위 수준의 데이터베이스 저장 구조를 사용한다. 성능을 향상시키기 위해 인덱싱과 같은 기술이 사용될 수 있다. 전통적인 저장 방식은 로우 지향적이지만, 컬럼 지향 및 상관 관계 데이터베이스도 존재한다.

구체화 뷰

[편집]

성능을 높이기 위해 저장 중복성이 자주 사용된다. 일반적인 사례는 자주 필요한 외부 뷰나 질의 결과로 구성된 구체화 뷰를 저장하는 것이다. 이러한 뷰를 저장하면 필요할 때마다 비용이 많이 드는 계산을 수행하는 것을 방지할 수 있다. 구체화 뷰의 단점은 원래 업데이트된 데이터베이스 데이터와 동기화 상태를 유지하기 위해 업데이트할 때 발생하는 오버헤드와 저장소 중복 비용이다.

레플리케이션

[편집]

경우에 따라 데이터베이스는 데이터 가용성을 높이기 위해(동일한 데이터베이스 객체에 대한 동시 다중 최종 사용자 액세스의 성능을 개선하고, 분산 데이터베이스의 부분적인 장애 발생 시 복원력을 제공하기 위해) 데이터베이스 객체 레플리케이션(하나 이상의 복사본 사용)을 통한 저장 중복을 사용한다. 복제된 객체의 업데이트는 객체 복사본 간에 동기화되어야 한다. 많은 경우 데이터베이스 전체가 복제된다.

가상화

[편집]

데이터 가상화를 통해 사용되는 데이터는 원래 위치에 유지되며, 여러 소스에 걸친 분석을 허용하기 위해 실시간 액세스가 구축된다. 이는 다양한 플랫폼의 데이터를 결합할 때의 호환성 문제와 같은 일부 기술적 어려움을 해결하고, 잘못된 데이터로 인한 오류 위험을 낮추며, 최신 데이터 사용을 보장하는 데 도움이 될 수 있다. 또한 개인 정보를 포함하는 새로운 데이터베이스 생성을 피함으로써 프라이버시 규정 준수를 더 쉽게 만들 수 있다. 그러나 데이터 가상화에서는 데이터의 로컬 복사본이 없기 때문에 필요한 모든 데이터 소스에 대한 연결이 작동 중이어야 하며, 이는 이 접근 방식의 주요 단점 중 하나이다.[38]

보안

[편집]

데이터베이스 보안은 데이터베이스 콘텐츠, 소유자 및 사용자를 보호하는 모든 다양한 측면을 다룬다. 이는 의도적인 무단 데이터베이스 사용으로부터의 보호에서부터 승인되지 않은 엔티티(예: 사람 또는 컴퓨터 프로그램)에 의한 비의도적인 데이터베이스 액세스에 이르기까지 다양하다.

데이터베이스 접근 제어는 누가(사람 또는 특정 컴퓨터 프로그램) 데이터베이스의 어떤 정보에 액세스할 수 있는지를 제어하는 문제를 다룬다. 정보는 특정 데이터베이스 객체(예: 레코드 유형, 특정 레코드, 데이터 구조), 특정 객체에 대한 특정 계산(예: 질의 유형 또는 특정 질의), 또는 전자에 대한 특정 액세스 경로 사용(예: 정보에 액세스하기 위해 특정 인덱스 또는 기타 데이터 구조 사용)으로 구성될 수 있다. 데이터베이스 접근 제어는 전용 보호 보안 DBMS 인터페이스를 사용하는 (데이터베이스 소유자에 의해) 특별히 권한을 부여받은 인원에 의해 설정된다.

이는 개인별로 직접 관리하거나, 개인과 권한을 그룹에 할당하거나, (가장 정교한 모델에서는) 개인과 그룹을 역할에 할당하고 그 역할에 자격을 부여함으로써 관리될 수 있다. 데이터 보안은 승인되지 않은 사용자가 데이터베이스를 보거나 업데이트하는 것을 방지한다. 비밀번호를 사용하여 사용자는 전체 데이터베이스 또는 "하위 스키마"라고 불리는 그 일부에 대한 액세스를 허용받는다. 예를 들어 직원 데이터베이스는 개별 직원에 대한 모든 데이터를 포함할 수 있지만, 한 사용자 그룹은 급여 데이터만 보도록 허용되고 다른 그룹은 근무 이력과 의료 데이터만 액세스하도록 허용될 수 있다. DBMS가 데이터베이스의 정보를 얻는 것뿐만 아니라 대화식으로 입력하고 업데이트하는 방법을 제공한다면, 이 기능은 개인 데이터베이스 관리를 가능하게 한다.

일반적으로 데이터 보안은 물리적으로(즉, 손상, 파괴 또는 제거로부터; 예: 물리 보안 참조) 또는 그들에 대한 해석이나 그 일부를 의미 있는 정보로 만드는 것(예: 비트 문자열을 보고 특정 유효한 신용카드 번호를 결론짓는 것; 예: 데이터 암호화 참조)으로부터 특정 데이터 덩어리를 보호하는 것을 다룬다.

변경 및 액세스 로깅은 누가 어떤 속성에 액세스했는지, 무엇이 변경되었는지, 언제 변경되었는지를 기록한다. 로깅 서비스는 액세스 발생 및 변경 기록을 유지함으로써 나중에 법의학적 데이터베이스 감사를 가능하게 한다. 때로는 이를 데이터베이스에 맡기는 대신 변경 사항을 기록하기 위해 애플리케이션 수준의 코드가 사용되기도 한다. 보안 침해를 탐지하기 위해 모니터링을 설정할 수 있다. 따라서 조직은 데이터베이스 보안이 제공하는 많은 이점 때문에 이를 진지하게 받아들여야 한다. 조직은 방화벽 침입, 바이러스 확산 및 랜섬웨어와 같은 보안 침해 및 해킹 활동으로부터 보호받을 것이다. 이는 외부로 절대 유출되어서는 안 되는 회사의 필수 정보를 보호하는 데 도움이 된다.[39]

트랜잭션 및 동시성

[편집]

데이터베이스 트랜잭션은 시스템 충돌 후 복구 시 어느 정도의 장애 허용성과 데이터 무결성을 도입하는 데 사용될 수 있다. 데이터베이스 트랜잭션은 작업의 단위로, 일반적으로 데이터베이스에 대한 여러 연산(예: 데이터베이스 객체 읽기, 쓰기, 잠금 획득 또는 해제 등)을 캡슐화하며, 데이터베이스 및 다른 시스템에서도 지원되는 추상화이다. 각 트랜잭션은 어떤 프로그램/코드 실행이 해당 트랜잭션에 포함되는지에 대해 잘 정의된 경계를 갖는다(트랜잭션 명령어를 통해 프로그래머에 의해 결정됨).

약어 ACID는 데이터베이스 트랜잭션의 몇 가지 이상적인 속성을 설명한다: 원자성, 일관성, 독립성 및 지속성.

마이그레이션

[편집]

하나의 DBMS로 구축된 데이터베이스는 다른 DBMS로 이식할 수 없다(즉, 다른 DBMS가 이를 실행할 수 없음). 그러나 어떤 상황에서는 데이터베이스를 한 DBMS에서 다른 DBMS로 마이그레이션하는 것이 바람직할 때가 있다. 그 이유는 주로 경제적(DBMS마다 총소유비용 또는 TCO가 다를 수 있음), 기능적 및 운영적(DBMS마다 기능이 다를 수 있음)인 것들이다. 마이그레이션은 데이터베이스를 한 DBMS 유형에서 다른 유형으로 변환하는 것을 포함한다. 변환 시 (가능하다면) 데이터베이스 관련 애플리케이션(즉, 모든 관련 애플리케이션 프로그램)을 손상되지 않은 상태로 유지해야 한다. 따라서 변환 시 데이터베이스의 개념적 및 외부 아키텍처 수준이 유지되어야 한다. 아키텍처 내부 수준의 일부 측면도 유지되기를 원할 수 있다. 복잡하거나 대규모인 데이터베이스 마이그레이션은 그 자체로 복잡하고 비용이 많이 드는 (일회성) 프로젝트일 수 있으며, 이는 마이그레이션 결정 시 고려되어야 한다. 이는 특정 DBMS 간의 마이그레이션을 돕는 도구가 존재함에도 불구하고 그러하다. 일반적으로 DBMS 벤더는 다른 인기 있는 DBMS로부터 데이터베이스를 가져오는 데 도움이 되는 도구를 제공한다.

구축, 유지보수 및 튜닝

[편집]

애플리케이션을 위한 데이터베이스를 설계한 후 다음 단계는 데이터베이스를 구축하는 것이다. 일반적으로 이 목적을 위해 사용될 적절한 범용 DBMS를 선택할 수 있다. DBMS는 데이터베이스 관리자가 DBMS의 각 데이터 모델 내에서 필요한 애플리케이션의 데이터 구조를 정의하는 데 사용할 수 있는 필요한 사용자 인터페이스를 제공한다. 다른 사용자 인터페이스는 필요한 DBMS 매개변수(예: 보안 관련, 저장소 할당 매개변수 등)를 선택하는 데 사용된다.

데이터베이스가 준비되면(모든 데이터 구조 및 기타 필요한 구성 요소가 정의됨), 이를 가동하기 전에 일반적으로 초기 애플리케이션 데이터로 채워진다(데이터베이스 초기화, 이는 일반적으로 별개의 프로젝트임. 많은 경우 대량 삽입을 지원하는 전문화된 DBMS 인터페이스를 사용함). 어떤 경우에는 애플리케이션 데이터가 비어 있는 상태로 데이터베이스 가동을 시작하고 운영 중에 데이터를 축적하기도 한다.

데이터베이스가 생성, 초기화 및 채워진 후에는 유지보수가 필요하다. 다양한 데이터베이스 매개변수를 변경해야 할 수 있으며, 더 나은 성능을 위해 데이터베이스를 튜닝(튜닝)해야 할 수 있다. 애플리케이션의 데이터 구조가 변경되거나 추가될 수 있고, 애플리케이션의 기능을 추가하기 위해 새로운 관련 애플리케이션 프로그램이 작성될 수도 있다.

백업 및 복구

[편집]

때때로 데이터베이스를 이전 상태로 되돌리고 싶을 때가 있다(많은 이유가 있는데, 예를 들어 소프트웨어 오류로 인해 데이터베이스가 손상된 것이 발견되거나 잘못된 데이터로 업데이트된 경우 등이다). 이를 달성하기 위해 백업 작업이 주기적으로 또는 지속적으로 수행되며, 여기서 각 원하는 데이터베이스 상태(즉, 데이터의 값과 데이터베이스의 데이터 구조 내의 임베딩)가 전용 백업 파일 내에 보관된다(이를 효과적으로 수행하기 위한 많은 기술이 존재한다). 데이터베이스 관리자가 데이터베이스를 이 상태로 되돌리기로 결정하면(예: 데이터베이스가 해당 상태였던 원하는 시점을 지정함), 이 파일들을 사용하여 해당 상태를 복구한다.

정적 분석

[편집]

소프트웨어 검증을 위한 정적 분석 기술은 질의 언어의 시나리오에도 적용될 수 있다. 특히, 추상 해석 프레임워크는 건전한 근사 기술을 지원하기 위한 방법으로서 관계형 데이터베이스용 질의 언어 분야로 확장되었다.[40] 질의 언어의 의미론은 데이터의 구체적인 도메인에 대한 적절한 추상화에 따라 튜닝될 수 있다. 관계형 데이터베이스 시스템의 추상화는 특히 미세 접근 제어, 워터마킹 등과 같은 보안 목적을 위해 많은 흥미로운 애플리케이션을 갖는다.

기타 기능

[편집]

기타 DBMS 기능은 다음과 같을 수 있다:

  • 데이터베이스 로그 – 실행된 기능의 이력을 유지하는 데 도움이 된다.
  • 특히 데이터 웨어하우스 시스템에서 그래프와 차트를 생성하기 위한 그래픽 구성 요소.
  • 질의 최적화 도구 – 모든 질의에 대해 질의 최적화를 수행하여 질의 결과를 계산하기 위해 실행될 효율적인 질의 계획(연산의 부분 순서(트리))을 선택한다. 특정 저장 엔진에 특화될 수 있다.
  • 데이터베이스 설계, 애플리케이션 프로그래밍, 애플리케이션 프로그램 유지보수, 데이터베이스 성능 분석 및 모니터링, 데이터베이스 구성 모니터링, DBMS 하드웨어 구성(DBMS 및 관련 데이터베이스는 컴퓨터, 네트워크 및 저장 장치에 걸쳐 있을 수 있음) 및 관련 데이터베이스 매핑(특히 분산 DBMS의 경우), 저장소 할당 및 데이터베이스 레이아웃 모니터링, 저장소 마이그레이션 등을 위한 도구 또는 훅.

점점 더, 데이터베이스 관리 및 소스 제어를 위해 이 모든 핵심 기능을 동일한 빌드, 테스트 및 배포 프레임워크로 통합하는 단일 시스템에 대한 요구가 늘어나고 있다. 소프트웨어 산업의 다른 발전에서 빌려와, 일부에서는 이러한 제품을 "데이터베이스용 데브옵스"라고 마케팅한다.[41]

설계 및 모델링

[편집]
Image

데이터베이스 설계자의 첫 번째 과제는 데이터베이스에 보관될 정보의 구조를 반영하는 개념적 데이터 모델을 제작하는 것이다. 이에 대한 일반적인 접근 방식은 종종 드로잉 도구의 도움을 받아 개체-관계 모델을 개발하는 것이다. 또 다른 인기 있는 접근 방식은 통합 모델링 언어이다. 성공적인 데이터 모델은 모델링되는 외부 세계의 가능한 상태를 정확하게 반영할 것이다. 예를 들어 사람이 하나 이상의 전화번호를 가질 수 있다면, 이 정보를 캡처할 수 있도록 허용할 것이다. 좋은 개념적 데이터 모델을 설계하려면 응용 도메인에 대한 깊은 이해가 필요하다. 여기에는 일반적으로 "고객이 공급업체도 될 수 있는가?", "하나의 제품이 두 가지 다른 형태의 포장으로 판매된다면, 그것들은 같은 제품인가 아니면 다른 제품인가?", "비행기가 뉴욕에서 프랑크푸르트를 거쳐 두바이로 비행한다면, 그것은 하나의 비행인가 두 개(또는 어쩌면 세 개)인가?"와 같이 조직이 관심을 갖는 것들에 대해 깊은 질문을 던지는 과정이 수반된다. 이러한 질문에 대한 답변은 엔티티(고객, 제품, 비행, 비행 구간)와 그들의 관계 및 속성에 사용되는 용어의 정의를 확립한다.

개념적 데이터 모델을 제작할 때 때로는 비즈니스 프로세스의 입력이나 조직의 워크플로 분석이 수반되기도 한다. 이는 데이터베이스에 어떤 정보가 필요한지, 그리고 무엇을 생략할 수 있는지 결정하는 데 도움이 된다. 예를 들어, 데이터베이스가 현재 데이터뿐만 아니라 과거 데이터도 보관해야 하는지 결정할 때 도움이 될 수 있다.

사용자가 만족하는 개념적 데이터 모델을 제작했다면, 다음 단계는 이를 데이터베이스 내에서 관련 데이터 구조를 구현하는 스키마로 변환하는 것이다. 이 과정은 종종 논리적 데이터베이스 설계라고 불리며, 결과물은 스키마 형태로 표현된 논리적 데이터 모델이다. 개념적 데이터 모델은 (적어도 이론적으로는) 데이터베이스 기술의 선택과 무관한 반면, 논리적 데이터 모델은 선택한 DBMS에서 지원하는 특정 데이터베이스 모델의 용어로 표현될 것이다. (데이터 모델과 데이터베이스 모델이라는 용어는 흔히 혼용되지만, 이 문서에서는 특정 데이터베이스의 설계를 위해 데이터 모델을 사용하고, 그 설계를 표현하는 데 사용되는 모델링 표기법을 위해 데이터베이스 모델을 사용한다.)

범용 데이터베이스를 위한 가장 인기 있는 데이터베이스 모델은 관계형 모델, 또는 더 정확하게는 SQL 언어로 표현되는 관계형 모델이다. 이 모델을 사용하여 논리적 데이터베이스 설계를 생성하는 과정은 정규화라고 알려진 체계적인 접근 방식을 사용한다. 정규화의 목표는 각 기초적인 "사실"이 한 곳에만 기록되도록 보장하여, 삽입, 업데이트 및 삭제 시 자동으로 일관성이 유지되도록 하는 것이다.

데이터베이스 설계의 마지막 단계는 특정 DBMS에 따라 달라지는 성능, 확장성, 복구, 보안 등에 영향을 미치는 결정을 내리는 것이다. 이는 종종 물리적 데이터베이스 설계라고 불리며, 결과물은 물리적 데이터 모델이다. 이 단계의 핵심 목표는 데이터 독립성으로, 성능 최적화 목적으로 내린 결정이 최종 사용자와 애플리케이션에 보이지 않아야 함을 의미한다. 데이터 독립성에는 두 가지 유형이 있다: 물리적 데이터 독립성과 논리적 데이터 독립성. 물리적 설계는 주로 성능 요구 사항에 의해 주도되며, 예상되는 워크로드와 액세스 패턴에 대한 충분한 지식, 그리고 선택한 DBMS가 제공하는 기능에 대한 깊은 이해가 필요하다.

물리적 데이터베이스 설계의 또 다른 측면은 보안이다. 이는 데이터베이스 객체에 대한 접근 제어를 정의하는 것뿐만 아니라 데이터 자체에 대한 보안 수준과 방법을 정의하는 것을 포함한다.

모델

[편집]
Image
다섯 가지 유형의 데이터베이스 모델 콜라주

데이터베이스 모델은 데이터베이스의 논리적 구조를 결정하고 근본적으로 데이터가 어떤 방식으로 저장, 조직 및 조작될 수 있는지를 결정하는 데이터 모델의 일종이다. 데이터베이스 모델의 가장 대중적인 예는 테이블 기반 형식을 사용하는 관계형 모델(또는 관계형의 SQL 근사치)이다.

데이터베이스를 위한 일반적인 논리적 데이터 모델은 다음과 같다:

객체 관계 데이터베이스는 두 가지 관련 구조를 결합한다.

물리적 데이터 모델은 다음과 같다:

기타 모델은 다음과 같다:

특정 유형의 데이터에 최적화된 전문화된 모델은 다음과 같다:

외부, 개념 및 내부 뷰

[편집]
Image
데이터에 대한 전통적인 뷰[42]

데이터베이스 관리 시스템은 데이터베이스 데이터에 대해 세 가지 뷰를 제공한다:

  • 외부 수준(external level)은 각 최종 사용자 그룹이 데이터베이스의 데이터 조직을 어떻게 보는지 정의한다. 단일 데이터베이스는 외부 수준에서 임의의 개수의 뷰를 가질 수 있다.
  • 개념 수준(conceptual level)(또는 논리 수준)은 다양한 외부 뷰를 호환 가능한 전역 뷰로 통합한다.[43] 이는 모든 외부 뷰의 합성을 제공한다. 이는 다양한 데이터베이스 최종 사용자의 범위를 벗어나며, 오히려 데이터베이스 애플리케이션 개발자와 데이터베이스 관리자의 관심 대상이다.
  • 내부 수준(internal level)(또는 물리 수준)은 DBMS 내부의 데이터 조직이다. 이는 비용, 성능, 확장성 및 기타 운영 문제와 관련이 있다. 성능을 높이기 위해 인덱스와 같은 저장 구조를 사용하여 데이터의 저장 레이아웃을 다룬다. 경우에 따라 그러한 중복성에 대한 성능적 정당성이 존재한다면, 일반 데이터로부터 계산된 개별 뷰의 데이터(구체화 뷰)를 저장하기도 한다. 이는 모든 활동에 걸쳐 전체적인 성능을 최적화하기 위해 충돌할 수도 있는 모든 외부 뷰의 성능 요구 사항의 균형을 맞춘다.

일반적으로 데이터에 대한 개념 뷰와 내부 뷰는 하나뿐이지만, 서로 다른 외부 뷰는 얼마든지 있을 수 있다. 이를 통해 사용자는 기술적, 처리적 관점이 아니라 비즈니스와 관련된 방식으로 데이터베이스 정보를 볼 수 있다. 예를 들어, 회사의 재무 부서는 회사의 지출의 일부로서 모든 직원의 급여 세부 정보가 필요하지만, 인적자원 부서의 관심사인 직원에 대한 세부 정보는 필요하지 않다. 따라서 부서마다 회사의 데이터베이스에 대해 서로 다른 뷰가 필요하다.

3단계 데이터베이스 아키텍처는 관계형 모델의 주요 초기 원동력 중 하나였던 데이터 독립성 개념과 관련이 있다.[43] 아이디어는 특정 수준에서 이루어진 변경이 더 높은 수준의 뷰에 영향을 미치지 않는다는 것이다. 예를 들어 내부 수준의 변경은 개념 수준 인터페이스를 사용하여 작성된 애플리케이션 프로그램에 영향을 미치지 않으며, 이는 성능 개선을 위한 물리적 변경의 영향을 줄여준다.

개념 뷰는 내부와 외부 사이에서 간접적인 수준을 제공한다. 한편으로는 서로 다른 외부 뷰 구조와 무관하게 데이터베이스의 공통 뷰를 제공하고, 다른 한편으로는 데이터가 어떻게 저장되거나 관리되는지(내부 수준)에 대한 세부 사항을 추상화한다. 원칙적으로 모든 수준, 심지어 모든 외부 뷰조차도 서로 다른 데이터 모델로 표현될 수 있다. 실제로는 일반적으로 주어진 DBMS가 외부 및 개념 수준 모두에 대해 동일한 데이터 모델(예: 관계형 모델)을 사용한다. DBMS 내부에 숨겨져 있고 구현에 따라 달라지는 내부 수준은 다른 수준의 세부 사항을 필요로 하며 자체적인 데이터 구조 유형을 사용한다.

연구

[편집]

데이터베이스 기술은 1960년대부터 학계와 기업의 연구 개발 그룹(예: IBM 리서치) 모두에서 활발한 연구 주제였다. 연구 활동에는 이론과 프로토타입 개발이 포함된다. 주목할 만한 연구 주제로는 모델, 원자적 트랜잭션 개념, 관련 동시성 제어 기술, 질의 언어 및 질의 최적화 방법, RAID 등이 있다.

데이터베이스 연구 분야에는 여러 전용 학술지(예: ACM Transactions on Database Systems-TODS, Data and Knowledge Engineering-DKE)와 연례 학술회의(예: ACM SIGMOD, ACM PODS, VLDB, IEEE ICDE)가 있다.

같이 보기

[편집]

각주

[편집]
  1. ↑ Ullman & Widom 1997, 1쪽.
  2. ↑ “Update Definition & Meaning”. 《Merriam-Webster》. 2024년 2월 25일에 원본 문서에서 보존된 문서.
  3. ↑ “Retrieval Definition & Meaning”. 《Merriam-Webster》. 2023년 6월 27일에 원본 문서에서 보존된 문서.
  4. ↑ “Administration Definition & Meaning”. 《Merriam-Webster》. 2023년 12월 6일에 원본 문서에서 보존된 문서.
  5. ↑ Tsitchizris & Lochovsky 1982.
  6. ↑ Beynon-Davies 2003.
  7. ↑ Nelson & Nelson 2001.
  8. ↑ Bachman 1973.
  9. ↑ “TOPDB Top Database index”. 《pypl.github.io》.
  10. ↑ “database, n”. 《OED Online》. Oxford University Press. June 2013. 2013년 7월 12일에 확인함. (구독이 필요합니다.)
  11. ↑ IBM Corporation (October 2013). “IBM Information Management System (IMS) 13 Transaction and Database Servers delivers high performance and low total cost of ownership”. 2014년 2월 20일에 확인함.
  12. 1 2 3 4 《RDBMS Plenary 1: Early Years》 (PDF). 인터뷰어: Burton Grad. Computer History Museum. 2007년 6월 12일. 2025년 5월 30일에 확인함.
  13. ↑ Codd 1970.
  14. ↑ Hershey & Easthope 1972.
  15. ↑ North 2010.
  16. ↑ Childs 1968a.
  17. ↑ Childs 1968b.
  18. ↑ M.A. Kahn; D.L. Rumelhart; B.L. Bronson (October 1977). 《MICRO Information Management System (Version 5.0) Reference Manual》. Institute of Labor and Industrial Relations (ILIR), University of Michigan and Wayne State University.
  19. ↑ “Oracle 30th Anniversary Timeline” (PDF). 2011년 3월 20일에 원본 문서 (PDF)에서 보존된 문서. 2017년 8월 23일에 확인함.
  20. 1 2 3 《RDBMS Plenary Session: The Later Years》 (PDF). 인터뷰어: Burton Grad. Computer History Museum. 2007년 6월 12일. 2025년 5월 30일에 확인함.
  21. ↑ Interview with Wayne Ratliff. The FoxPro History. Retrieved on 2013-07-12.
  22. ↑ Development of an object-oriented DBMS; Portland, Oregon, United States; Pages: 472–482; 1986; ISBN 0-89791-204-7
  23. ↑ Jordan, Meghan. “NoSQL Latency” (미국 영어). 《ScyllaDB》. 2025년 6월 9일에 확인함.
  24. ↑ “SQL vs. NoSQL: Full comparison of features, differences, and more” (영어). 《www.testgorilla.com》. 2025년 6월 9일에 확인함.
  25. ↑ Graves, Steve. "COTS Databases For Embedded Systems" 보관됨 2007-11-14 - 웨이백 머신, Embedded Computing Design magazine, January 2007. Retrieved on August 13, 2008.
  26. ↑ Argumentation in Artificial Intelligence by Iyad Rahwan, Guillermo R. Simari
  27. ↑ “OWL DL Semantics”. 2010년 12월 10일에 확인함.
  28. ↑ Connolly & Begg 2014, 64쪽.
  29. ↑ Connolly & Begg 2014, 97–102쪽.
  30. ↑ Connolly & Begg 2014, 102쪽.
  31. ↑ Chong 외. 2007.
  32. ↑ Connolly & Begg 2014, 106–113쪽.
  33. ↑ Connolly & Begg 2014, 65쪽.
  34. ↑ Chapple 2005.
  35. ↑ “Structured Query Language (SQL)”. International Business Machines. 2006년 10월 27일. 2007년 6월 10일에 확인함.
  36. ↑ Wagner 2010.
  37. ↑ Ramalho, J.C.; Faria, L.; Helder, S.; Coutada, M. (2013년 12월 31일). 《Database Preservation Toolkit: A flexible tool to normalize and give access to databases》. 《Biblioteca Nacional de Portugal》 (University of Minho).
  38. ↑ Paiho, Satu; Tuominen, Pekka; Rökman, Jyri; Ylikerälä, Markus; Pajula, Juha; Siikavirta, Hanne (2022). 《Opportunities of collected city data for smart cities》. 《IET Smart Cities》 4. 275–291쪽. doi:10.1049/smc2.12044. ISSN 2631-7680. S2CID 253467923.
  39. ↑ David Y. Chan; Victoria Chiu; Miklos A. Vasarhelyi (2018). 《Continuous auditing : theory and application》 1판. Bingley, UK: Emerald Publishing. ISBN 978-1-78743-413-4. OCLC 1029759767.
  40. ↑ Halder & Cortesi 2011.
  41. ↑ Ben Linders (2016년 1월 28일). “How Database Administration Fits into DevOps”. 2017년 4월 15일에 확인함.
  42. ↑ itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX) 보관됨 2013-12-03 - 웨이백 머신. 21 December 1993.
  43. 1 2 Date 2003, 31–32쪽.
내용주
  1. ↑ 이 기사는 DB2 릴리스 9 하나에만 750명이 참여하여 5년의 개발 기간이 소요되었다고 인용한다.[31]

참고 문헌

[편집]
  • Elmasri, Navathe:Fundamentals of database systems, Addision Wesley.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=데이터베이스&oldid=41502109"