데이터베이스

Database
이 기사는 컴퓨팅 개념에 관한 것입니다. 일반 개념의 인스턴스는 데이터베이스 목록을 참조하십시오.
SQL select 문과 그 결과

컴퓨팅에서 데이터베이스는 데이터를 캡처하고 분석하기 위해 최종 사용자, 응용 프로그램 및 데이터베이스 자체와 상호 작용하는 소프트웨어인 DBMS(Database Management System)를 사용하여 데이터를 조직화한 데이터 모음 또는 데이터 저장소 유형입니다. DBMS는 데이터베이스를 관리하기 위해 제공되는 핵심 설비를 추가로 포함합니다. 데이터베이스, DBMS 및 관련 응용 프로그램의 합계를 데이터베이스 시스템이라고 할 수 있습니다. 종종 "데이터베이스"라는 용어는 DBMS, 데이터베이스 시스템 또는 데이터베이스와 연관된 응용 프로그램을 가리키는 데에도 느슨하게 사용됩니다.

작은 데이터베이스는 파일 시스템에 저장할 수 있으며, 큰 데이터베이스는 컴퓨터 클러스터나 클라우드 스토리지에 호스팅됩니다. 데이터베이스의 설계는 데이터 모델링, 효율적인 데이터 표현 및 저장, 쿼리 언어, 민감한 데이터의 보안 및 개인 정보 보호, 동시 액세스 및 내결함성 지원을 포함한 분산 컴퓨팅 문제를 포함한 공식적인 기술 및 실용적인 고려 사항에 걸쳐 있습니다.

컴퓨터 과학자는 지원하는 데이터베이스 모델에 따라 데이터베이스 관리 시스템을 분류할 수 있습니다. 관계형 데이터베이스는 1980년대에 지배적이 되었습니다. 이러한 모델 데이터는 일련의 테이블에 행과 열로 표시되며, 대다수는 SQL을 사용하여 데이터를 작성하고 쿼리합니다. 2000년대 들어 비관계형 데이터베이스는 서로 다른 쿼리 언어를 사용하기 때문에 NoSQL로 통칭되어 인기를 끌었습니다.

용어 및 개요

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

데이터베이스와 데이터베이스 간의 긴밀한 관계 때문에 데이터베이스를 조작하는 데 사용되는 DBMS를 모두 가리키는 데 "데이터베이스"라는 용어가 종종 무심코 사용됩니다.

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

기존 DBMS는 데이터베이스와 데이터베이스의 데이터를 관리할 수 있는 다양한 기능을 제공하며, 이는 크게 4가지 기능 그룹으로 분류할 수 있습니다.

  • 데이터 정의 – 데이터의 조직을 정의하는 정의를 생성, 수정 및 제거합니다.
  • 업데이트 – 실제 데이터의 삽입,[2] 수정 및 삭제
  • 검색 – 직접 사용하거나 다른 응용 프로그램에서 추가 처리할 수 있는 형태로 정보를 제공합니다. 검색된 데이터는 데이터베이스에 저장된 것과 기본적으로 동일한 형태로 제공되거나 데이터베이스의 기존 데이터를 변경 또는 결합하여 얻은 새로운 형태로 제공될 수 있습니다.[3]
  • 관리 – 사용자 등록 및 모니터링, 데이터 보안 적용, 성능 모니터링, 데이터 무결성 유지,[4] 동시성 제어 처리, 예기치 않은 시스템 장애와 같은 일부 이벤트로 인해 손상된 정보 복구

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

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

DBMS는 상당한 시장을 구성하고 있기 때문에 컴퓨터 및 스토리지 공급업체는 자체 개발 계획에 DBMS 요구 사항을 고려하는 경우가 많습니다.[7]

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

역사

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

두 가지 주요 초기 항법 데이터 모델은 계층 모델과 CODASYL 모델(네트워크 모델)이었습니다. 이들은 한 레코드에서 다른 레코드로 관계를 추적하기 위해 포인터(종종 물리적 디스크 주소)를 사용하는 것이 특징입니다.

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

객체 데이터베이스는 객체-관계 임피던스 불일치의 불편함을 극복하기 위해 1980년대에 개발되었으며, 이로 인해 "post-관계"라는 용어가 결합되고 하이브리드 객체-관계 데이터베이스가 개발되었습니다.

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

1960년대 내비게이션 DBMS

추가 정보: 네비게이션 데이터베이스
내비게이션 CODASYL 데이터베이스 모델의 기본구조

데이터베이스라는 용어의 도입은 1960년대 중반 이후부터 직접 액세스 스토리지(디스크 및 드럼)의 가용성과 일치했습니다. 이 용어는 일상적인 일괄 처리가 아닌 공유 대화형 사용을 가능하게 하여 과거의 테이프 기반 시스템과 대조를 이룹니다. 옥스포드 영어 사전은 1962년 캘리포니아 시스템 개발 회사의 보고서를 특정한 기술적 의미에서 "데이터 기반"이라는 용어를 처음으로 사용한 것으로 인용하고 있습니다.[10]

컴퓨터의 속도와 성능이 향상됨에 따라 여러 범용 데이터베이스 시스템이 등장했습니다. 1960년대 중반까지 이러한 시스템 중 많은 것이 상업적으로 사용되었습니다. 표준에 대한 관심이 커지기 시작했고, 그러한 제품 중 하나인 통합 데이터 스토어(IDS)의 저자인 찰스 바흐만(Charles Bachman)은 COBOL의 생성 및 표준화를 담당하는 그룹인 CODASYL 내에서 데이터베이스 태스크 그룹(Database Task Group)을 설립했습니다. 1971년, 데이터베이스 태스크 그룹은 CODASYL 접근 방식으로 알려지게 된 그들의 표준을 제공했고, 곧 이 접근 방식을 기반으로 한 많은 상용 제품들이 시장에 진출했습니다.

CODASYL 접근 방식은 애플리케이션이 대규모 네트워크로 형성된 연결된 데이터 세트를 탐색할 수 있는 기능을 제공했습니다. 응용 프로그램은 다음 세 가지 방법 중 하나로 레코드를 찾을 수 있습니다.

  1. 기본 키 사용(CALL 키로 알려져 있으며, 일반적으로 해싱으로 구현됨)
  2. 한 레코드에서 다른 레코드로 관계 탐색(집합이라고 함)
  3. 모든 레코드를 순차적으로 스캔하는 중

이후 시스템에서는 B-트리를 추가하여 대체 액세스 경로를 제공했습니다. 많은 CODASYL 데이터베이스는 최종 사용자를 위한 선언 쿼리 언어를 추가했습니다(내비게이션 API와 구별됨). 하지만 CODASYL 데이터베이스는 복잡하고 유용한 애플리케이션을 생성하기 위해 상당한 훈련과 노력이 필요했습니다.

또한 IBM은 1966년에 정보 관리 시스템(IMS)으로 알려진 자체 DBMS를 보유했습니다. IMS는 시스템/360의 아폴로 프로그램을 위해 작성된 소프트웨어 개발이었습니다. IMS는 일반적으로 CODASYL과 개념이 비슷했지만 CODASYL의 네트워크 모델 대신 데이터 탐색 모델에 엄격한 계층 구조를 사용했습니다. 두 개념 모두 나중에 데이터에 접근하는 방식으로 인해 네비게이션 데이터베이스로 알려지게 되었습니다. 이 용어는 바흐만의 1973년 튜링상 프레젠테이션인 프로그래머가 네비게이터로 사용하면서 대중화되었습니다. IMS는 IBM에 의해 계층형 데이터베이스로 분류됩니다. IDMS와 신컴시스템즈의 TOTAL 데이터베이스는 네트워크 데이터베이스로 분류됩니다. IMS는 2014년 현재 사용되고 있습니다.[11]

1970년대, 관계형 DBMS

에드가 F. Codd는 캘리포니아 산호세에 있는 IBM에서 하드 디스크 시스템 개발에 주로 참여했던 사무실 중 하나에서 일했습니다. 그는 CODASYL 접근 방식의 내비게이션 모델, 특히 "검색" 시설의 부족에 불만을 가지고 있었습니다. 1970년에 그는 데이터베이스 구축에 대한 새로운 접근 방식의 개요를 설명하는 여러 논문을 작성했으며, 이는 결국 혁신적인 대규모 공유 데이터 뱅크를 위한 데이터 관계형 모델(A Relational Model of Data for Large Shared Data Banks)로 끝을 맺었습니다.[12]

이 논문에서 그는 대용량 데이터베이스를 저장하고 작업하는 새로운 시스템에 대해 설명했습니다. CODASYL처럼 자유로운 형태의 레코드의 링크된 목록에 레코드가 저장되는 대신, 코드의 아이디어는 데이터를 여러 개의 "테이블"로 구성하고, 각 테이블은 다른 유형의 엔티티에 사용되는 것이었습니다. 각 표에는 엔티티의 속성을 포함하는 고정된 수의 열이 포함됩니다. 각 테이블의 하나 이상의 열이 테이블의 행을 고유하게 식별할 수 있는 기본 키로 지정되었습니다. 테이블 간의 상호 참조는 항상 디스크 주소가 아닌 이러한 기본 키를 사용했으며 쿼리는 이러한 키 관계를 기반으로 테이블에 참여합니다. 관계형 미적분학의 수학적 체계를 기반으로 한 일련의 연산을 사용합니다(모델의 이름은 여기서 따옴). 데이터를 정규화된 테이블(또는 관계)로 분할하여 각 "사실"이 단 한 번만 저장되도록 하여 업데이트 작업을 간소화하는 것을 목표로 합니다. 뷰라는 가상 테이블은 사용자마다 다른 방식으로 데이터를 표시할 수 있지만 뷰를 직접 업데이트할 수는 없습니다.

Codd는 모델을 정의하기 위해 표, 행, 열 대신 관계, 튜플, 도메인을 사용했습니다. 현재 익숙한 용어는 초기 구현에서 비롯되었습니다. Codd는 나중에 실제 구현이 모델의 기반이 된 수학적 기초에서 벗어나는 경향이 있다고 비판했습니다.

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

디스크 주소가 아닌 기본 키(사용자 지향 식별자)를 사용하여 교차 테이블 관계를 나타내는 데에는 두 가지 주요 동기가 있었습니다. 엔지니어링 관점에서는 값비싼 데이터베이스 재구성 없이 테이블을 재배치하고 크기를 조정할 수 있었습니다. 그러나 코드는 의미론의 차이에 더 관심이 있었습니다: 명시적 식별자를 사용함으로써 깨끗한 수학적 정의로 업데이트 연산을 더 쉽게 정의할 수 있었고, 또한 쿼리 연산을 1차 술어 미적분학의 확립된 학문적 측면에서 정의할 수 있게 해주었습니다. 이러한 연산은 수학적 특성이 깨끗하기 때문에 쿼리 최적화의 기본이 되는 증명 가능한 올바른 방법으로 쿼리를 다시 작성하는 것이 가능해집니다. 계층 모델이나 네트워크 모델에 비해 표현력의 손실은 없지만, 테이블 간의 연결은 더 이상 명확하지 않습니다.

계층 및 네트워크 모델에서 레코드는 복잡한 내부 구조를 갖도록 허용되었습니다. 예를 들어, 직원의 급여 내역은 직원 기록 내에서 "반복 그룹"으로 표시될 수 있습니다. 관계형 모델에서 정규화 과정은 이러한 내부 구조가 논리적 키로만 연결된 여러 테이블에 보유된 데이터로 대체되는 결과를 낳았습니다.

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

Codd는 디스크 주소가 아닌 논리적 식별자를 사용하여 행/기록을 식별할 뿐만 아니라 응용 프로그램이 여러 레코드에서 데이터를 조립하는 방식을 변경했습니다. 애플리케이션이 링크를 탐색하여 한 번에 하나의 레코드를 수집하도록 요구하는 것이 아니라, 데이터를 찾아야 하는 액세스 경로가 아닌 필요한 데이터를 표현하는 선언 쿼리 언어를 사용합니다. 데이터에 대한 효율적인 접근 경로를 찾는 것은 애플리케이션 프로그래머가 아닌 데이터베이스 관리 시스템의 책임이 되었습니다. 쿼리 최적화라고 불리는 이 과정은 쿼리가 수학적 논리의 측면에서 표현된다는 사실에 의존했습니다.

Codd의 논문은 Eugene Wong과 Michael Stonebraker라는 버클리 대학의 두 사람이 주웠습니다. 그들은 이미 지리 데이터베이스 프로젝트에 할당된 자금과 코드를 생산하기 위한 학생 프로그래머를 사용하여 INGRES로 알려진 프로젝트를 시작했습니다. 1973년부터 INGRES는 일반적으로 널리 사용할 준비가 된 첫 번째 테스트 제품을 1979년에 제공했습니다. INGRES는 데이터 액세스를 위해 QUEL로 알려진 "언어"를 사용하는 것을 포함하여 여러 면에서 R 시스템과 유사했습니다. 시간이 지남에 따라 INGRES는 새로운 SQL 표준으로 이동했습니다.

IBM 자체적으로 관계형 모델인 PRTV의 테스트 구현과 운영 모델인 Business System 12의 테스트 구현이 모두 중단되었습니다. Honeywell은 Multics용 MRDS를 작성했으며, 현재 두 가지 새로운 구현이 있습니다. Alphora Dataphor and Rel. 일반적으로 관계형이라고 불리는 대부분의 다른 DBMS 구현은 실제로 SQL DBMS입니다.

1970년 미시간 대학교는 D.L. Childs의 Set-Theoretic Data 모델을 기반으로 한 MICRO Information Management System의[13] 개발을 시작했습니다.[14][15][16] MICRO는 미국 노동부, 미국 환경보호청, 앨버타 대학교, 미시간 대학교, 웨인 주립 대학교의 연구원들에 의해 매우 큰 데이터 세트를 관리하는 데 사용되었습니다. 미시간 터미널 시스템을 사용하여 IBM 메인프레임 컴퓨터에서 실행되었습니다.[17] 이 시스템은 1998년까지 생산 상태를 유지했습니다.

통합적 접근법

주요 기사: 데이터베이스 머신

1970년대와 1980년대에는 하드웨어와 소프트웨어가 통합된 데이터베이스 시스템을 구축하려는 시도가 있었습니다. 기본 철학은 이러한 통합이 더 낮은 비용으로 더 높은 성능을 제공할 것이라는 것이었습니다. Teradata의 초기 제품인 IBM System/38과 Britton Lee, Inc. 데이터베이스 머신이 그 예입니다.

데이터베이스 관리를 위한 하드웨어 지원에 대한 또 다른 접근 방식은 프로그래밍 가능한 검색 기능을 갖춘 하드웨어 디스크 컨트롤러인 ICL의 CAFS 액셀러레이터였습니다. 장기적으로 이러한 노력은 일반적으로 성공하지 못했는데, 이는 전문 데이터베이스 기계가 범용 컴퓨터의 빠른 발전과 발전에 보조를 맞출 수 없었기 때문입니다. 따라서 오늘날 대부분의 데이터베이스 시스템은 범용 컴퓨터 데이터 스토리지를 사용하는 범용 하드웨어에서 실행되는 소프트웨어 시스템입니다. 그러나 이 아이디어는 여전히 Netzliza 및 Oracle(Exadata)과 같은 일부 회사에서 특정 애플리케이션에서 추구하고 있습니다.

1970년대 후반, SQL DBMS

IBM은 1970년대 초부터 시스템 R로서 코드의 개념을 바탕으로 느슨하게 프로토타입 시스템 작업을 시작했습니다. 첫 번째 버전은 1974/5에 준비되었으며, 데이터를 분할할 수 있는 다중 테이블 시스템에서 작업을 시작하여 레코드에 대한 모든 데이터를 하나의 큰 "청크"에 저장할 필요가 없었습니다. 이후의 다중 사용자 버전은 1978년과 1979년에 고객에 의해 테스트되었으며, 이때 표준화된 쿼리 언어인 SQL이[citation needed] 추가되었습니다. Codd의 아이디어는 CODASYL보다 실행 가능하면서도 우수한 것으로 자리매김하고 있었고, IBM은 SQL/DS로 알려진 R 시스템의 진정한 운영 버전과 나중에 데이터베이스 2(IBM Db2)를 개발하도록 추진했습니다.

래리 엘리슨(Larry Ellison)의 Oracle Database(또는 간단히 말해 Oracle)는 시스템 R에 대한 IBM의 논문을 기반으로 다른 체인에서 시작되었습니다. Oracle V1 구현은 1978년에 완료되었지만 Ellison이 IBM을 제치고 1979년에 출시된 Oracle Version 2에 이르러서야 완료되었습니다.[18]

스톤브레이커는 INGRES의 교훈을 적용하여 새로운 데이터베이스인 Postgres를 개발했습니다. 이 데이터베이스는 현재 Postgre로 알려져 있습니다.SQL. PostgreSQL은 종종 글로벌 미션 크리티컬 애플리케이션(.org 및 .info 도메인 이름 레지스터는 많은 대기업 및 금융 기관과 마찬가지로 기본 데이터 저장소로 사용)에 사용됩니다.

스웨덴에서도 Codd의 논문을 읽고 1970년대 중반에 Uppsala University에서 Mimer SQL을 개발했습니다. 1984년, 이 프로젝트는 독립 기업으로 통합되었습니다.

또 다른 데이터 모델인 개체-관계 모델은 1976년에 등장하여 이전의 관계 모델보다 더 친숙한 설명을 강조하면서 데이터베이스 설계에 대한 인기를 얻었습니다. 이후 관계형 모델에 대한 데이터 모델링 구조로 개체-관계형 구조가 개조되었으며 둘 사이의 차이는 무관하게 되었습니다.[citation needed]

1980년대, 데스크톱에서

1980년대는 데스크톱 컴퓨팅 시대를 열었습니다. 새로운 컴퓨터는 Lotus 1-2-3과 같은 스프레드시트와 dBASE와 같은 데이터베이스 소프트웨어를 사용자에게 제공했습니다. dBASE 제품은 가볍고 컴퓨터 사용자라면 누구나 쉽게 이해할 수 있습니다. dBASE의 제작자인 Wayne Ratlif는 "dBASE는 많은 더러운 작업이 이미 완료되었다는 점에서 BASEIC, C, Fortran, 코볼과 같은 프로그램과 다릅니다. 데이터 조작은 사용자가 하는 것이 아니라 dBASE가 하기 때문에 사용자는 파일을 열고, 읽고, 닫고, 공간 할당을 관리하는 더러운 세부 사항을 처리할 필요 없이 자신이 하는 일에 집중할 수 있습니다."[19] dBASE는 1980년대와 1990년대 초반에 가장 많이 팔린 소프트웨어 타이틀 중 하나였습니다.

1990년대, 객체 지향적

1990년대에는 객체 지향 프로그래밍의 증가와 함께 다양한 데이터베이스의 데이터 처리 방식이 증가했습니다. 프로그래머와 디자이너는 데이터베이스의 데이터를 개체로 취급하기 시작했습니다. 즉, 어떤 사람의 데이터가 데이터베이스에 있었다면, 이제는 그 사람의 주소, 전화번호, 나이와 같은 속성이 외부 데이터가 아닌 그 사람의 것으로 간주되었다는 것입니다. 이를 통해 데이터 간의 관계를 개별 필드가 아닌 개체 및 개체의 속성과 관련시킬 수 있습니다.[20] "객체-관계 임피던스 불일치"라는 용어는 프로그래밍된 객체와 데이터베이스 테이블 간의 변환의 불편함을 설명했습니다. 객체 데이터베이스와 객체-관계 데이터베이스는 프로그래머가 순수한 관계형 SQL의 대안으로 사용할 수 있는 객체 지향 언어(때로는 SQL의 확장으로)를 제공함으로써 이 문제를 해결하려고 시도합니다. 프로그래밍 측면에서는 ORM(object-relational mapping)으로 알려진 라이브러리가 동일한 문제를 해결하려고 시도합니다.

2000년대, NoSQL 및 NewSQL

주요 기사: NoSQL 및 NewSQL

XML 데이터베이스는 XML 문서 속성을 기반으로 쿼리할 수 있는 구조화된 문서 지향 데이터베이스의 한 유형입니다. XML 데이터베이스는 데이터를 문서 모음으로 편리하게 볼 수 있는 응용 프로그램에 주로 사용되며, 매우 유연한 것부터 매우 엄격한 것까지 다양한 구조를 가질 수 있습니다. 예를 들어 과학 기사, 특허, 세금 신고 및 인사 기록 등이 있습니다.

NoSQL 데이터베이스는 매우 빠르고 고정된 테이블 스키마가 필요하지 않으며 정규화되지 않은 데이터를 저장하여 조인 작업을 피하고 수평으로 확장하도록 설계된 경우가 많습니다.

최근에는 파티션 허용오차가 높은 대규모 분산 데이터베이스에 대한 요구가 강하지만, CAP 정리에 따르면 분산 시스템이 일관성, 가용성 및 파티션 허용오차 보장을 동시에 제공하는 것은 불가능합니다. 분산 시스템은 이러한 두 가지 보장 중 하나를 동시에 충족할 수 있지만 세 가지 모두를 충족할 수는 없습니다. 이러한 이유로 많은 NoSQL 데이터베이스는 데이터 일관성 수준을 낮추면서 가용성과 파티션 허용 오차를 모두 보장하기 위해 궁극적인 일관성이라고 하는 것을 사용하고 있습니다.

NewSQL은 온라인 트랜잭션 처리(읽기-쓰기) 워크로드에 대해 NoSQL 시스템과 동일한 확장 가능한 성능을 제공하는 동시에 SQL을 사용하고 기존 데이터베이스 시스템의 ACID 보장을 유지하는 것을 목표로 하는 최신 관계형 데이터베이스 클래스입니다.

사용사례

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

데이터베이스는 관리 정보와 엔지니어링 데이터 또는 경제 모델과 같은 보다 전문화된 데이터를 보유하는 데 사용됩니다. 예를 들어, 컴퓨터화된 라이브러리 시스템, 항공편 예약 시스템, 컴퓨터화된 부품 인벤토리 시스템 및 웹 사이트를 데이터베이스에 웹 페이지 모음으로 저장하는 많은 콘텐츠 관리 시스템이 있습니다.

분류

데이터베이스를 분류하는 한 가지 방법은 내용 유형(예: 서지, 문서 텍스트, 통계 또는 멀티미디어 개체)을 포함합니다. 또 다른 방법은 회계, 음악 작곡, 영화, 은행, 제조 또는 보험과 같은 응용 분야입니다. 세 번째 방법은 데이터베이스 구조나 인터페이스 유형과 같은 일부 기술적 측면입니다. 이 섹션에서는 다양한 유형의 데이터베이스를 특성화하는 데 사용되는 형용사 몇 가지를 나열합니다.

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

데이터베이스관리시스템

Connolly와 Begg는 데이터베이스 관리 시스템(DBMS)을 "사용자가 데이터베이스에 대한 액세스를 정의, 생성, 유지 및 제어할 수 있는 소프트웨어 시스템"으로 정의합니다.[24] DBMS의 예로는 MySQL, MariaDB, Postgre 등이 있습니다.SQL, Microsoft SQL Server, Oracle Database 및 Microsoft Access.

DBMS 머리글자는 때때로 기본 데이터베이스 모델을 나타내기 위해 확장되며, 관계형의 경우 RDBMS, 객체(지향)의 경우 OODBMS, 객체-관계형 모델의 경우 ORDBMS가 사용됩니다. 다른 확장은 분산 데이터베이스 관리 시스템의 DDBMS와 같은 일부 다른 특성을 나타낼 수 있습니다.

DBMS가 제공하는 기능은 매우 다양할 수 있습니다. 핵심 기능은 데이터의 저장, 검색 및 업데이트입니다. Codd는 본격적인 범용 DBMS가 제공해야 할 기능과 서비스를 다음과 같이 제안했습니다.[25]

  • 데이터 저장, 검색 및 업데이트
  • 메타데이터를 설명하는 사용자 액세스 가능한 카탈로그 또는 데이터 사전
  • 트랜잭션 및 동시성 지원
  • 데이터베이스가 손상된 경우 복구하기 위한 시설
  • 데이터 접근 및 갱신 승인 지원
  • 원격 위치에서 액세스 지원
  • 데이터베이스의 데이터가 특정 규칙을 준수하는지 확인하기 위한 제약 조건 적용

또한 DBMS는 데이터베이스를 효과적으로 관리하기 위해 필요한 일련의 유틸리티를 제공할 것으로 예상되며, 여기에는 가져오기, 내보내기, 모니터링, 조각 모음 및 분석 유틸리티가 포함됩니다.[26] 데이터베이스와 응용 프로그램 인터페이스 간에 상호 작용하는 DBMS의 핵심 부분을 데이터베이스 엔진이라고도 합니다.

종종 DBMS에는 정적 및 동적으로 조정할 수 있는 구성 매개 변수(예: 데이터베이스가 사용할 수 있는 서버의 최대 주 메모리 양)가 있습니다. 수동 구성의 양을 최소화하는 추세이며, 임베디드 데이터베이스와 같은 경우 제로 관리를 목표로 할 필요성이 무엇보다 중요합니다.

대기업 DBMS는 규모와 기능이 증가하는 경향이 있으며, 일생 동안 최대 수천 년 동안의 개발 노력이 수반되었습니다.[a]

초기 다중 사용자 DBMS는 일반적으로 응용 프로그램이 터미널 또는 터미널 에뮬레이션 소프트웨어를 통해 액세스할 수 있는 동일한 컴퓨터에 상주하도록 허용했습니다. 클라이언트-서버 아키텍처는 애플리케이션이 클라이언트 데스크톱에 상주하고 데이터베이스가 서버에 상주하여 프로세스를 분산할 수 있도록 하는 개발이었습니다. 이는 데이터베이스가 인접 계층에만 직접 연결된 웹 브라우저를 통해 최종 사용자 인터페이스를 갖춘 애플리케이션 서버와 웹 서버를 통합하는 멀티티어 아키텍처로 발전했습니다.[28]

범용 DBMS는 API(Public Application Programming Interface)와 선택적으로 SQL과 같은 데이터베이스 언어를 위한 프로세서를 제공하여 응용 프로그램이 데이터베이스와 상호 작용하고 조작할 수 있도록 합니다. 특수목적 DBMS는 개인 API를 사용할 수 있으며, 하나의 애플리케이션에 특별히 맞춤화되어 연동될 수 있습니다. 예를 들어, 이메일 시스템은 메시지 삽입, 메시지 삭제, 첨부 파일 처리, 블록 목록 조회, 메시지를 이메일 주소로 연결하는 등 범용 DBMS의 많은 기능을 수행하지만 이러한 기능은 이메일을 처리하는 데 필요한 것으로 제한됩니다.

어플

주요기사 : 데이터베이스 어플리케이션

데이터베이스와의 외부 상호 작용은 DBMS와 인터페이스하는 응용 프로그램을 통해 이루어질 것입니다.[29] 이것은 사용자가 SQL 쿼리를 텍스트 또는 그래픽으로 실행할 수 있는 데이터베이스 도구에서부터 정보를 저장하고 검색하기 위해 데이터베이스를 사용하는 웹 사이트에 이르기까지 다양합니다.

응용 프로그램 인터페이스

프로그래머는 응용 프로그램 인터페이스(API) 또는 데이터베이스 언어를 통해 데이터베이스(데이터 소스라고도 함)에 대한 상호 작용을 코딩합니다. 선택된 특정 API 또는 언어는 DBMS에 의해 지원되어야 하며, 가능하면 전처리기 또는 브리징 API를 통해 간접적으로 지원되어야 합니다. 일부 API는 데이터베이스 독립을 목표로 하며, ODBC는 일반적으로 알려진 예입니다. 다른 일반적인 API로는 JDBC와 ADO가 있습니다.NET.

데이터베이스 언어

데이터베이스 언어는 특수 목적 언어로서 다음 작업 중 하나 이상을 허용하며 때로는 하위 언어로 구분되기도 합니다.

데이터베이스 언어는 특정 데이터 모델에 따라 다릅니다. 주목할 만한 예는 다음과 같습니다.

  • SQL은 데이터 정의, 데이터 조작 및 쿼리의 역할을 단일 언어로 결합합니다. 이 언어는 관계형 모델을 위한 최초의 상용 언어 중 하나였지만, 코드에서 설명한 관계형 모델에서 몇 가지 면에서 벗어납니다(예를 들어, 테이블의 행과 열은 순서를 지정할 수 있습니다). SQL은 1986년에 미국 표준 협회(ANSI)의 표준이 되었고, 1987년에 국제 표준화 기구(ISO)의 표준이 되었습니다. 표준은 이후 정기적으로 개선되어 왔으며 모든 주류 상용 관계형 DBMS에 의해 (다양한 수준의 적합성을 갖추고) 지원됩니다.[30][31]
  • OQL은 개체 모델 언어 표준(Object Data Management Group)입니다. JDOQL 및 EJB QL과 같은 일부 최신 쿼리 언어의 설계에 영향을 미쳤습니다.
  • XQuery는 MarkLogic 및 eXist와 같은 XML 데이터베이스 시스템, Oracle 및 Db2와 같은 XML 기능을 갖춘 관계형 데이터베이스, 그리고 Saxon과 같은 인메모리 XML 프로세서에 의해 구현되는 표준 XML 쿼리 언어입니다.
  • SQL/XML은 XQuery를 SQL과 결합합니다.[32]

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

  • DBMS별 구성 및 스토리지 엔진 관리
  • 조회 결과를 수정하기 위한 계산(계산, 합산, 평균화, 정렬, 그룹화, 교차 참조 등)
  • 제약 조건 시행(예: 자동차 데이터베이스에서 한 대당 한 대의 엔진 유형만 허용)
  • 프로그래머 편의를 위한 쿼리 언어의 응용 프로그래밍 인터페이스 버전

보관소

주요 기사: 컴퓨터 데이터 저장 및 데이터베이스 엔진

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

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

스토리지 엔진은 다양한 저수준 데이터베이스 저장 구조를 사용하여 데이터 모델을 직렬화하여 선택한 매체에 쓸 수 있습니다. 인덱싱(indexing)과 같은 기술을 사용하여 성능을 향상시킬 수 있습니다. 기존 스토리지는 행 중심이지만 열 중심 및 상관 관계 데이터베이스도 있습니다.

구체화된 보기

주요 기사: 구체화 뷰

성능을 높이기 위해 스토리지 이중화를 사용하는 경우가 많습니다. 일반적인 예는 자주 필요한 외부 보기 또는 쿼리 결과로 구성된 구체화된 보기를 저장하는 것입니다. 이러한 뷰를 저장하면 필요할 때마다 비용이 많이 드는 컴퓨팅을 절약할 수 있습니다. 구체화된 보기의 단점은 원래 업데이트된 데이터베이스 데이터와 동기화되도록 업데이트할 때 발생하는 오버헤드와 스토리지 이중화 비용입니다.

복제

참고 항목: 복제(컴퓨팅) § 데이터베이스 복제

때때로 데이터베이스는 데이터 가용성을 높이기 위해 데이터베이스 객체 복제(하나 이상의 복사본 포함)를 통해 스토리지 이중화를 사용합니다(동일한 데이터베이스 객체에 대한 여러 최종 사용자 액세스 성능 향상 및 분산 데이터베이스의 부분 장애 시 복원력 제공). 복제된 개체의 업데이트는 개체 복사본 간에 동기화되어야 합니다. 많은 경우 데이터베이스 전체가 복제됩니다.

가상화

데이터 가상화를 사용하면 사용된 데이터가 원래 위치에 그대로 유지되고 실시간 액세스가 설정되어 여러 소스에서 분석이 가능합니다. 이를 통해 다양한 플랫폼의 데이터를 결합할 때 호환성 문제와 같은 일부 기술적 문제를 해결하고, 데이터 오류로 인한 오류 위험을 줄이며, 최신 데이터를 사용할 수 있도록 보장할 수 있습니다. 또한 개인 정보가 포함된 새로운 데이터베이스 생성을 방지하면 개인 정보 보호 규정을 쉽게 준수할 수 있습니다. 그러나 데이터 가상화를 사용하면 데이터의 로컬 복사본이 없기 때문에 필요한 모든 데이터 소스에 대한 연결이 작동해야 하는데, 이는 접근 방식의 주요 단점 중 하나입니다.[34]

보안.

주요 기사: 데이터베이스 보안

데이터베이스 보안은 데이터베이스 콘텐츠, 소유자 및 사용자를 보호하는 다양한 측면을 다룹니다. 의도적인 무단 데이터베이스 사용으로부터 무단 개체(예: 사람 또는 컴퓨터 프로그램)에 의한 의도하지 않은 데이터베이스 액세스에 대한 보호까지 다양합니다.

데이터베이스 액세스 제어는 사용자(사용자 또는 특정 컴퓨터 프로그램)가 데이터베이스의 어떤 정보에 액세스할 수 있는지 제어하는 것을 다룹니다. 정보는 특정 데이터베이스 객체(예를 들어, 레코드 유형, 특정 레코드, 데이터 구조), 특정 객체에 대한 특정 계산(예를 들어, 쿼리 유형 또는 특정 쿼리), 또는 전자에 대한 특정 액세스 경로(예를 들어, 특정 인덱스 또는 다른 데이터 구조를 사용하여 정보에 액세스하는 것)을 포함할 수 있습니다. 데이터베이스 액세스 제어는 전용 보호된 보안 DBMS 인터페이스를 사용하는 특별한 권한을 가진(데이터베이스 소유자에 의해) 담당자가 설정합니다.

이는 개인 단위로 직접 관리하거나 개인과 권한을 그룹에 할당하거나 개인과 그룹을 역할에 할당하여 (가장 정교한 모델로) 관리할 수 있으며, 이는 권한이 부여됩니다. 데이터 보안으로 권한이 없는 사용자가 데이터베이스를 보거나 업데이트할 수 없습니다. 암호를 사용하면 사용자는 "구독 테마"라고 불리는 전체 데이터베이스 또는 하위 집합에 액세스할 수 있습니다. 예를 들어, 직원 데이터베이스에는 개별 직원에 대한 모든 데이터가 포함될 수 있지만, 한 그룹의 사용자는 급여 데이터만 볼 수 있는 권한을 부여받을 수 있으며, 다른 사용자는 업무 기록 및 의료 데이터만 볼 수 있습니다. DBMS가 데이터베이스를 대화식으로 입력 및 업데이트하고 조회할 수 있는 방법을 제공하는 경우, 이 기능을 통해 개인 데이터베이스를 관리할 수 있습니다.

일반적으로 데이터 보안은 특정 데이터 청크를 물리적으로(예를 들어, 손상, 파괴 또는 제거로부터) 보호하거나, 데이터 청크를 해석하거나, 데이터 청크를 의미 있는 정보로 해석하는 것을 다룹니다(예를 들어, 데이터 청크가 구성하는 비트의 문자열을 살펴봄으로써). 특정 유효한 신용카드 번호의 결론(예: 데이터 암호화 참조).

누가 어떤 속성에 액세스했는지, 무엇이 변경되었는지, 언제 변경되었는지 기록을 변경하고 액세스합니다. 로깅 서비스는 액세스 발생 및 변경 사항에 대한 기록을 보관하여 나중에 포렌식 데이터베이스 감사를 수행할 수 있습니다. 때때로 응용 프로그램 수준의 코드를 사용하여 변경 사항을 데이터베이스에 남겨두는 것이 아니라 변경 사항을 기록합니다. 보안 위반을 탐지하기 위해 모니터링을 설정할 수 있습니다. 따라서 조직은 데이터베이스 보안이 제공하는 많은 이점 때문에 데이터베이스 보안을 심각하게 고려해야 합니다. 조직은 방화벽 침입, 바이러스 확산 및 랜섬웨어와 같은 보안 침해 및 해킹 활동으로부터 보호됩니다. 이는 어떠한 이유로도 외부인과 공유할 수 없는 회사의 필수 정보를 보호하는 데 도움이 됩니다.[35]

거래 및 동시성

추가 정보: 동시성 제어

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

약자 ACID는 데이터베이스 트랜잭션의 몇 가지 이상적인 속성, 즉 원자성, 일관성, 격리 및 내구성을 설명합니다.

마이그레이션

참고 항목: 데이터 마이그레이션 § 데이터베이스 마이그레이션

하나의 DBMS로 구축된 데이터베이스는 다른 DBMS로 이동할 수 없습니다(즉, 다른 DBMS는 데이터베이스를 실행할 수 없습니다). 그러나 경우에 따라 데이터베이스를 한 DBMS에서 다른 DBMS로 마이그레이션하는 것이 좋습니다. 그 이유는 주로 경제성(DBMS마다 소유 비용 또는 TCO가 다를 수 있음), 기능 및 운영성(DBMS마다 기능이 다를 수 있음)입니다. 마이그레이션에는 데이터베이스가 한 DBMS 유형에서 다른 유형으로 변환되는 과정이 포함됩니다. 변환은 데이터베이스 관련 응용 프로그램(즉, 모든 관련 응용 프로그램)을 그대로 유지해야 합니다. 따라서 데이터베이스의 개념적 및 외부 아키텍처 수준은 전환 과정에서 유지되어야 합니다. 아키텍처 내부 레벨의 일부 측면도 유지되는 것이 바람직할 수 있습니다. 복잡하거나 대규모 데이터베이스 마이그레이션은 그 자체로 복잡하고 비용이 많이 드는(일회성) 프로젝트일 수 있으며, 이는 마이그레이션 결정에 고려되어야 합니다. 이는 특정 DBMS 간의 마이그레이션을 돕기 위한 도구가 존재할 수 있음에도 불구하고 발생합니다. 일반적으로 DBMS 공급업체는 다른 인기 DBMS에서 데이터베이스를 가져오는 데 도움이 되는 도구를 제공합니다.

건축, 유지보수 및 튜닝

주요 기사: 데이터베이스 튜닝

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

데이터베이스가 준비되면(데이터 구조 및 기타 필요한 구성 요소가 모두 정의됨), 일반적으로 초기 응용 프로그램의 데이터(데이터베이스 초기화, 일반적으로 별개의 프로젝트임; 대량 삽입을 지원하는 특수 DBMS 인터페이스 사용)가 작동하기 전에 채워집니다. 응용 프로그램 데이터가 비어 있는 상태에서 데이터베이스가 작동하게 되고, 작동 중에 데이터가 축적되는 경우도 있습니다.

데이터베이스가 생성된 후 초기화되고 채워져야 합니다. 다양한 데이터베이스 매개 변수를 변경해야 할 수도 있고 더 나은 성능을 위해 데이터베이스를 조정(조정)해야 할 수도 있습니다. 응용 프로그램의 데이터 구조를 변경하거나 추가할 수도 있고, 응용 프로그램의 기능을 추가하기 위해 새로운 관련 응용 프로그램을 작성할 수도 있습니다.

백업 및 복원

주요 기사: 백업

때때로 데이터베이스를 이전 상태로 되돌리는 것이 필요합니다(예: 소프트웨어 오류로 인해 데이터베이스가 손상된 경우 또는 잘못된 데이터로 업데이트된 경우). 이를 위해 백업 작업은 때때로 또는 지속적으로 수행되며, 여기서 각 원하는 데이터베이스 상태(즉, 데이터의 값 및 데이터베이스의 데이터 구조에 포함된 값)는 전용 백업 파일 내에 유지됩니다(이를 효과적으로 수행하기 위한 많은 기술이 존재함). 데이터베이스 관리자가 데이터베이스를 이 상태로 되돌리기로 결정한 경우(예: 데이터베이스가 이 상태에 있을 때 원하는 시점으로 이 상태를 지정하여) 이 파일을 사용하여 이 상태를 복원합니다.

정태분석

소프트웨어 검증을 위한 정적 분석 기법은 쿼리 언어의 시나리오에서도 적용할 수 있습니다. 특히 *추상적 해석 프레임워크는 소리 근사 기법을 지원하기 위한 방법으로 관계형 데이터베이스에 대한 쿼리 언어 분야로 확장되었습니다.[36] 쿼리 언어의 의미론은 데이터의 구체적인 영역의 적절한 추상화에 따라 조정될 수 있습니다. 관계형 데이터베이스 시스템의 추상화는 특히 세분화된 액세스 제어, 워터마킹 등과 같은 보안 목적으로 많은 흥미로운 응용 분야를 가지고 있습니다.

기타 기능

다른 DBMS 기능에는 다음이 포함될 수 있습니다.

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

데이터베이스 관리 및 소스 제어를 위해 이러한 모든 핵심 기능을 동일한 빌드, 테스트 및 배포 프레임워크에 통합하는 단일 시스템에 대한 요구가 점차 증가하고 있습니다. 소프트웨어 산업의 다른 개발에서 차용하여 "데이터베이스용 데브옵스(DevOps for database)"와 같은 제품을 판매합니다.[37]

설계 및 모델링

주요 기사: 데이터베이스 설계

데이터베이스 설계자의 첫 번째 과제는 데이터베이스에 보유할 정보의 구조를 반영한 개념적 데이터 모델을 제작하는 것입니다. 이에 대한 일반적인 접근 방식은 도면 도구를 사용하여 기업-관계 모델을 개발하는 것입니다. 또 다른 인기 있는 접근 방식은 통합 모델링 언어입니다. 성공적인 데이터 모델은 모델링되는 외부 세계의 가능한 상태를 정확하게 반영합니다. 예를 들어, 사람들이 둘 이상의 전화 번호를 가질 수 있는 경우, 이 정보를 캡처할 수 있습니다. 좋은 개념의 데이터 모델을 설계하려면 애플리케이션 영역을 잘 이해해야 합니다. 일반적으로 "고객도 공급자가 될 수 있습니까?" 또는 "제품이 두 가지 다른 형태의 포장으로 판매되는 경우 동일한 제품입니까, 아니면 다른 제품입니까?"와 같이 조직이 관심 있는 것에 대해 깊은 질문을 하는 것이 포함됩니다. 또는 "만약 비행기가 뉴욕에서 프랑크푸르트를 거쳐 두바이로 날아간다면, 그것은 한 번 혹은 두 번의 비행인가요? (혹은 심지어 세 번의 비행도 가능한가요?)" 이러한 질문에 대한 답변은 기업(고객, 제품, 항공편, 항공편 부문)과 그 관계 및 속성에 사용되는 용어의 정의를 수립합니다.

개념적 데이터 모델을 생성하는 데에는 비즈니스 프로세스의 입력 또는 조직 내 워크플로우 분석이 포함되기도 합니다. 이를 통해 데이터베이스에 필요한 정보와 누락될 수 있는 정보를 확인하는 데 도움이 될 수 있습니다. 예를 들어, 데이터베이스가 현재 데이터뿐만 아니라 과거 데이터를 보유해야 하는지 여부를 결정할 때 도움이 될 수 있습니다.

사용자가 만족하는 개념적인 데이터 모델을 생성한 다음 단계는 이를 데이터베이스 내의 관련 데이터 구조를 구현하는 스키마로 변환하는 것입니다. 이 과정을 흔히 논리 데이터베이스 설계라고 하며, 출력물은 스키마 형태로 표현된 논리 데이터 모델입니다. 개념적 데이터 모델은 (적어도 이론적으로는) 데이터베이스 기술의 선택에 독립적이지만, 논리적 데이터 모델은 선택된 DBMS에 의해 지원되는 특정 데이터베이스 모델의 관점에서 표현될 것입니다. (데이터 모델과 데이터베이스 모델이라는 용어는 종종 서로 교환 가능하게 사용됩니다.) 그러나 이 글에서는 특정 데이터베이스의 설계를 위해 데이터 모델을 사용하고, 그 설계를 표현하는 데 사용되는 모델링 표기를 위해 데이터베이스 모델을 사용합니다.

범용 데이터베이스에서 가장 인기 있는 데이터베이스 모델은 관계형 모델, 즉 SQL 언어로 표현되는 관계형 모델입니다. 이 모델을 사용하여 논리 데이터베이스 설계를 만드는 과정은 정규화라는 방법적 접근 방식을 사용합니다. 정규화의 목표는 각 기본 "사실"이 한 곳에만 기록되도록 하여 삽입, 업데이트 및 삭제가 자동으로 일관성을 유지하도록 하는 것입니다.

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

물리적 데이터베이스 설계의 또 다른 측면은 보안입니다. 데이터베이스 개체에 대한 액세스 제어를 정의할 뿐만 아니라 데이터 자체에 대한 보안 수준 및 방법을 정의합니다.

모델

주요 기사: 데이터베이스 모델
5가지 유형의 데이터베이스 모델 콜라주

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

데이터베이스의 일반적인 논리 데이터 모델은 다음과 같습니다.

객체-관계형 데이터베이스는 두 개의 관련 구조를 결합합니다.

물리적 데이터 모델은 다음과 같습니다.

다른 모델은 다음과 같습니다.

특수 모델은 특정 유형의 데이터에 최적화되어 있습니다.

외부적, 개념적, 내부적 관점

기존[38] 데이터 보기

데이터베이스 관리 시스템은 데이터베이스 데이터의 세 가지 보기를 제공합니다.

  • 외부 수준은 각 최종 사용자 그룹이 데이터베이스의 데이터 조직을 보는 방법을 정의합니다. 단일 데이터베이스는 외부 수준에서 원하는 개수의 보기를 가질 수 있습니다.
  • 개념 수준(또는 논리 수준)은 다양한 외부 보기를 호환 가능한 글로벌 보기로 통합합니다.[39] 모든 외부 견해의 종합을 제공합니다. 다양한 데이터베이스 최종 사용자의 범위에서 벗어나 데이터베이스 애플리케이션 개발자와 데이터베이스 관리자에게 오히려 관심이 있습니다.
  • 내부 레벨(또는 물리적 레벨)은 DBMS 내부의 데이터의 내부 구성입니다. 비용, 성능, 확장성 및 기타 운영 문제와 관련이 있습니다. 인덱스와 같은 스토리지 구조를 사용하여 데이터의 스토리지 레이아웃을 처리하여 성능을 향상시킵니다. 이러한 이중화에 대한 성능 정당성이 존재하는 경우 일반 데이터에서 계산된 개별 뷰(구체화된 뷰)의 데이터를 저장하는 경우도 있습니다. 모든 활동에 걸쳐 전체 성능을 최적화하기 위해 충돌 가능성이 있는 외부 뷰의 모든 성능 요구 사항을 균형 있게 조정합니다.

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

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

개념적 관점은 내부와 외부 사이의 수준의 간접성을 제공합니다. 한편으로는 다양한 외부 보기 구조에 관계없이 데이터베이스의 공통 보기를 제공하고 다른 한편으로는 데이터가 저장 또는 관리되는 방식(내부 수준)의 세부 정보를 추상화합니다. 원칙적으로 모든 수준, 심지어 모든 외부 뷰는 다른 데이터 모델에 의해 제시될 수 있습니다. 실제로 주어진 DBMS는 일반적으로 외부 수준과 개념 수준(예: 관계형 모델) 모두에 대해 동일한 데이터 모델을 사용합니다. DBMS 내부에 숨겨져 있고 구현에 따라 달라지는 내부 레벨은 다른 수준의 세부 정보가 필요하며 자체 유형의 데이터 구조 유형을 사용합니다.

조사.

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

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

참고 항목

주제 안내서는 데이터베이스 개요를 참조하십시오.

메모들

  1. ^ 이 기사는 DB2 릴리스 9에만 750명이 참여한 개발 기간을 5년으로 인용했습니다.[27]

참고문헌

  1. ^ Ullman & Widom 1997, p. 1.
  2. ^ "Update Definition & Meaning". Merriam-Webster. Archived from the original on Feb 25, 2024.
  3. ^ "Retrieval Definition & Meaning". Merriam-Webster. Archived from the original on Jun 27, 2023.
  4. ^ "Administration Definition & Meaning". Merriam-Webster. Archived from the original on Dec 6, 2023.
  5. ^ 치치즈리스 & 로초프스키 1982.
  6. ^ 비욘-데이비스 2003.
  7. ^ Nelson & Nelson 2001.
  8. ^ 바흐만 1973.
  9. ^ "TOPDB Top Database index". pypl.github.io.
  10. ^ "database, n". OED Online. Oxford University Press. June 2013. Retrieved July 12, 2013. (구독 필수)
  11. ^ IBM Corporation (October 2013). "IBM Information Management System (IMS) 13 Transaction and Database Servers delivers high performance and low total cost of ownership". Retrieved Feb 20, 2014.
  12. ^ 코드드 1970.
  13. ^ 허쉬 & 이스트호프 1972.
  14. ^ 북 2010.
  15. ^ 차일드 1968a.
  16. ^ 차일드 1968b.
  17. ^ 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.
  18. ^ "Oracle 30th Anniversary Timeline" (PDF). Archived (PDF) from the original on 2011-03-20. Retrieved 23 August 2017.
  19. ^ 웨인 라틀리프와의 인터뷰. 폭스 프로 히스토리. 2013-07-12에 회수되었습니다.
  20. ^ 객체지향 DBMS 개발; 미국 포틀랜드, 오레곤; 페이지: 472-482; 1986; ISBN 0-89791-204-7
  21. ^ 그레이브스, 스티브. "임베디드 시스템을 위한 COTS 데이터베이스" 2007-11-14 "Wayback Machine, Embedded Computing Design 잡지, 2007년 1월. 2008년 8월 13일에 검색되었습니다.
  22. ^ 이야드 라환, 기예르모 R.의 인공지능에서의 논증 시마리
  23. ^ "OWL DL Semantics". Retrieved 10 December 2010.
  24. ^ Connolly & Begg 2014, p. 64.
  25. ^ Connolly & Begg 2014, pp. 97–102.
  26. ^ Connolly & Begg 2014, p. 102.
  27. ^ Chong et al. 2007.
  28. ^ Connolly & Begg 2014, pp. 106-113.
  29. ^ Connolly & Begg 2014, p. 65.
  30. ^ Chapple 2005.
  31. ^ "Structured Query Language (SQL)". International Business Machines. October 27, 2006. Retrieved 2007-06-10.
  32. ^ 바그너 2010.
  33. ^ Ramalho, J.C.; Faria, L.; Helder, S.; Coutada, M. (31 December 2013). "Database Preservation Toolkit: A flexible tool to normalize and give access to databases". Biblioteca Nacional de Portugal (BNP). University of Minho.
  34. ^ 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 (4): 275–291. doi:10.1049/smc2.12044. S2CID 253467923.
  35. ^ David Y. Chan; Victoria Chiu; Miklos A. Vasarhelyi (2018). Continuous auditing : theory and application (1st ed.). Bingley, UK: Emerald Publishing. ISBN 978-1-78743-413-4. OCLC 1029759767.
  36. ^ Halder & Cortesi 2011.
  37. ^ Ben Linders (January 28, 2016). "How Database Administration Fits into DevOps". Retrieved April 15, 2017.
  38. ^ itl.nist.gov (1993) 정보 모델링을 위한 통합 정의 (IDEFIX) 2013-12-03 at the Wayback Machine. 1993. 12. 21.
  39. ^ a b 2003년 12월 31~32일

원천

추가읽기

외부 링크