[TIL]데이터베이스 시스템 - CH.01

TIL

데이터베이스 시스템 7th를 읽고 요약 및 정리한 글 입니다.

Chapter 01 - 서론

데이터베이스(database)는 보통 데이터들의 모임을 일컫는 말로서, 흔히 조직과 관련된 정보를 포함한다. 그리고 데이터베이스 관리 시스템(database-management system)은 이 데이터베이스를 관리하기 위한 프로그램으로써 데이터베이스에 정보를 저장하고, 이를 검색하기 위한 편리하고도 효율적인 환경을 제공한다. 주로 데이터베이스는 대규모의 정보를 관리하도록 설계된다. 데이터 관리에는 정보 저장 구조를 정의하는 작업과 저장된 정보를 조작하기 위한 기법이 모두 포함된다. 또한, 데이터베이스 시스템은 저장된 정보를 시스템 고장이나 모든 불법적인 접근 등으로부터 안전하게 보호해야 하며, 데이터가 여러 사용자 간에 공유될 경우 생길 수 있는 예기치 않은 이상 결과를 방지해야 한다.

1.1 데이터베이스 시스템의 응용

초기 데이터베이스 응용은 단순하고 형식화된 구조화 데이터만 가지고 있었다. 하지만 반대로 최신 데이터베이스 시스템은 약하게 구조화된 데이터와 매우 가변적인 형태의 데이터에 대해서 효율성을 얻기 위해 데이터 구조의 공통성을 활용한다. 결국 데이터베이스 시스템은 양적으로 매우 크고, 내용적으로 복잡하고 다양한 데이터 집합을 관리하는 소프트웨어 시스템이다. 이런 복잡성을 관리하기 위해 우리는 추상화(abstraction)를 활용한다. 즉 데이터베이스 시스템은 대규모의 복잡한 데이터에 대해서 더 단순하고 추상화된 관점을 제공한다. 그래서 사용자와 응용 프로그래머들은 데이터가 실제로 어떻게 저장되고 조직화되었는지에 대해 자세한 사항을 알 필요가 없다.

---

오늘날 크게 보면 데이터베이스는 아래와 같은 두 가지 모드로 사용된다.

• 온라인 트랜잭션 처리(online transaction processing)를 지원하는 모드. 이 모드에서는 대규모 사용자들이 데이터베이스를 사용하며 각 사용자는 비교적 적은 양의 데이터에 대한 검색이나 갱신을 주로 수행한다. 대부분의 데이터베이스 응용을 위한 주 모드(primary mode)이다.
• 데이터 분석(data analysis)을 지원하는 모드. 즉, 비즈니스 결정을 내리기 위해 결론을 끌어내고 규칙을 추론하거나, 어떤 결정을 내리기 위해서 데이터를 분석하는 것.

1.2 데이터베이스 시스템의 목적

만일 데이터베이스가 없는 상황에서 특정 사람 A가 파일 F를 저장해야 하는 경우를 가정하면, 먼저 운영체제상의 파일 시스템에 이 파일 F를 저장하는 방법을 생각할 수 있다. 이런 경우 사용자가 이 파일 시스템을 사용하기 위해서는(F에 대학생들의 정보가 기록되었다고 가정하면) 학생 추가, 삭제, 학점 부여, 평점 계산과도 같은 기능을 수행하는 다양한 응용 프로그램이 필요하다.

위와 같이 데이터를 처리하는 시스템을 파일 처리 시스템(file-processing system)이라고 한다. 이 파일 처리 시스템의 주요 단점은 아래와 같다.

• 데이터의 중복과 비일관성. - 파일과 응용 프로그램은 장기간에 걸쳐 서로 다른 많은 프로그래머에 의해 개발되므로 파일이 서로 다른 형식을 갖기 쉽고, 응용 프로그램이 서로 다른 언어로 작성될 수도 있다. 하지만 더 큰 문제는 중복과 비일관성의 문제이다. 예를들어 전공별로 학생의 정보를 저장하는 파일 처리 시스템이 존재한다고 했을 때 특정학생 A가 음악과 미술을 모두 전공하는 수재일 경우 A에 대한 정보는 음악을 전공하는 학생들의 파일과, 미술을 전공하는 학생들의 파일 모두에 존재할 것이다. 이러한 중복은 저장 공간의 낭비를 나타내고 접근 비용도 늘어나게 한다. 또, A의 정보가 잘못되어 음악 전공생 파일에서는 A의 정보를 수정하였지만, 미술 전공생 파일에서는 A의 정보가 수정되지 않는 데이터의 비일관성(data inconsistency)동일한 데이터의 여러 사본이 서로 다른 값을 보유하고 있는 상태-가 나타날 수 있다.
• 데이터 접근의 어려움. - 기존의 파일 처리 시스템을 기반으로 새로운 파일을 만들고 싶을 때. 예를들어 단과대별 학생들의 정보가 기록되어 있는 파일이 있고, 전체 대학생의 정보를 모아놓은 파일을 생성하고 싶을 때는 새로운 응용 프로그램을 개발해야한다. 그리고 또, 몇 몇 단과대를 포함시키지 않은 대학생 목록이 필요해질 경우 또 새로운 응용 프로그램을 개발해야한다. 이처럼 기존의 파일 처리 시스템에서는 필요한 데이터를 편리하고 효율적으로 검색하기가 힘들다.
• 데이터 고립. - 데이터가 여러 파일에 흩어져 있는 데다 파일 형식이 서로 다르기 때문에 원하는 데이터를 검색하는 프로그램을 새로 작성하기 어렵다.
• 무결성 문제. - 데이터베이스 내에 저장된 데이터 값은 어떤 형식의 일관성 제약 조건(consistency constraint)을 만족해야 한다. 하지만 데이터가 파일로 흩어져 있고, 그걸 관리하는 여러 프로그램이 존재하는 경우 각각의 데이터 값의 제약 조건이 변경되었을 경우 프로그램을 다시 변경해야 한다.
• 원자성 문제. - 다른 장치처럼 컴퓨터 시스템도 고장이 날 수 있다. 이런 경우 시스템이 고장을 일으켰을 때 데이터를 고장 전의 일관성 있는 상태로 유지시키는 일이 매우 중요하다. 예를들어 A가 B에게 100만원을 송금하는 도중 시스템이 다운되었을 경우, A는 100만원을 인출했는데 B는 100만원을 받지못해 데이터베이스의 비일관성을 초래할 수 있다. 이런 경우를 방지하기 위해 반드시 출금과 입금이 동시에 이루어지든지, 둘 다 이루어지지 않든지 해야 한다. 즉 예금 이체는 원자적(atomic)-일련의 과정 전체가 수행되든지 아니면 어느 것도 수행되지 않아야 한다.-이어야 한다. 기존 파일 접근 시스템에서는 이러한 원자성을 보장하기 어렵다.
• 동시 접근의 문제. - 시스템의 전반적인 성능을 향상하고 응답 시간을 단축하기 위해 많은 시스템은 여러 사용자가 데이터를 동시에 갱신할 수 있도록 한다. 이런 상황에서는 동일한 데이터가 여러 사용자에 의해 동시에 갱신될 수 있고, 이 때문에 데이터의 비일관성이 야기될 수 있다. 하지만 데이터는 사전에 조정되지 않은 수많은 응용 프로그램에 의해 접근되므로 이를 관리하기가 어렵다. 파일 처리 시스템에서는 이런 동시 접근의 문제를 해결하기가 어렵다.
• 보안 문제. - 데이터베이스 시스템에서는 모든 사용자가 모든 데이터에 접근하는 것은 아니다. 하지만 파일 처리 시스템에서는 이런 보안에 관한 제약 조건을 지키기가 어렵다.

이러한 어려움 때문에 파일 기반 응용을 데이터베이스 시스템으로 전환하였고, 우리는 이 문제르 해결하기 위해 개발된 데이터베이스 시스템의 개념과 알고리즘을 공부할 것이다.

1.3 데이터의 관점

데이터베이스 시스템은 서로 관련이 있는 파일의 모임이자 사용자로 하여금 이 파일에 접근하거나 이를 수정하도록 하는 프로그램의 집합니다. 데이터베이스 시스템의 주요 목적은 사용자에게 데이터에 관한 추상적인 관점을 제공하는 것이다. 즉, 시스템은 데이터가 어떻게 저장되고 유지되는지에 관한 세부 사항은 사용자로 부터 은폐한다.

1.3.1 데이터 모델

데이터베이스 구조의 기반이 되는 것이 데이터 모델로서, 이는 데이터, 데이터들 사이의 관계, 데이터의 의미 그리고 일관성 제약 조건 등을 기술하기 위한 개념적 표현의 집합이다.

앞으로 이 책에서 다룰 데이터 모델은 크게 네 개로 분류된다.

• 관계형 모델(Relational Model) - 관계형 모델은 데이터와 이들 데이터 사이의 관계를 나타내기 위해 테이블의 모임을 사용한다. 각 테이블은 교유한 이름을 가진 여러개의 열(column)로 구성된다. 테이블은 릴레이션(relation)이라고도 부른다.
• 개체-관계 모델(Entity-Relationship Model) - 개체-관계 데이터 모델(E-R 모델)은 기본적인 객체들의 집합인 개체(entity)와 이러한 개체들 간의 관계(relationship)를 사용한다.
• 반구조형 데이터 모델(Semi-structured Data Model) - 반구조형 데이터 모델은 같은 형식을 갖고 있으나 다소 다른 속성을 가진 개별적 데이터 항목을 기술하기 위한 비정형 데이터 모델이다. 이는 앞에서 소개한 모델들이 특정 형식의 데이터 항목에 대해서는 동일한 속성의 집합만 갖도록 허용한다는 점에서 대조를 이룬다. JSON과 확장성 마크업 언어(extensible markup language)인 XML이 반구조형 데이터를 표현하는데 널리 사용된다.
• 객체 기반 데이터 모델(Object-Based Data Model) - 객체 지향 프로그래밍 초기에 활용된 별도의 객체 지향 데이터 모델

1.3.2 관계형 데이터 모델

관계형 모델에서 데이터는 테이블로 표현된다. 각 테이블은 다수의 열을 가지고 있으면 각 열을 유일한 이름을 갖는다. 테이블의 각 행은 정보의 한 조각을 표현한다.

1.3.3 데이터 추상화

시스템이 원활하게 사용되기 위해서는 데이터 검색이 효율적으로 이루어져야 한다. 이런 목적을 이루기 위해 데이터베이스 내의 데이터를 효율적으로 표현하기 위한 여러 가지 복잡한 데이터 구조가 제안되었다. 많은 데이터베이스 시스템의 경우 사용자 대부분이 컴퓨터를 잘 다루지 못하는 일반인이므로, 여러 단계의 데이터 추상화(data abstraction)를 통해 이러한 복잡한 구조를 되도록이면 감추어 사용자의 이해와 편의를 도와야 한다.

• 물리적 단계(Physical level) - 추상화의 최하위 단계. 데이터가 실제로 어떻게 저장되는지 기술한다. 물리적 단계에서는 복잡한 하위 단계의 데이터 구조가 상세히 기술되어 있다.
• 논리적 단계(Logical level) - 그 다음의 상위 단계. 어떤 데이터가 저장되어 있는지 그리고 데이터들 사이에는 어떤 관계가 있는지를 기술한다. 논리적 단계에서는 전체 데이터베이스를 몇 개의 비교적 간단한 데이터 구조를 이용하여 기술한다. 이러한 논리적 단계의 간단한 구조를 구현하기 위해서는 복잡한 물리적 단계의 구조를 알아야 하는 것이 사실이나, 논리적 단계의 사용자는 이러한 복잡한 구조에 대해 전혀 알 필요가 없다. 이것을 물리적 데이터 독립성(physical data independence)이라고 한다.
• 뷰 단계(View level) - 추상화의 최상위 단계. 전체 데이터베이스의 일부분만을 기술한다. 대부분의 데이터베이스 시스템 사용자는 데이터베이스에 저장된 모든 데이터에 관심이 있는 것이 아니라 극히 일부분에만 관심이 있다. 뷰 단계는 이러한 사용자가 시스템을 간단히 이용할 수 있도록 정의된다.

1.3.4 인스턴스와 스키아

데이터베이스는 정보가 추가되고 삭제됨에 따라 시시각각 변한다. 어느 특정한 순간에 데이터베이스에 저장되어 있는 정보의 모임을 데이터베이스의 인스턴스(instance)라고 한다. 이와 대조적으로 데이터베이스의 전체적인 설계를 이야기할 때는 데이터베이스 스키마(schema)라 한다.

1.4 데이터베이스 언어

데이터베이스 시스템은 데이터베이스 스키마를 기술하는 데이터 정의 언어(data definition language, DDL)와 데이터베이스 질의 및 갱신을 표현하는 데이터 조작 언어(data manipulation language, DML)를 제공한다. 실제로 데이터 정의 언어와 데이터 조작 언어의 경계는 명확히 구분되어 있지 않다.

1.4.1 데이터 정의 언어(DDL)

데이터 정의 언어(DDL)라는 특수한 언어로 표현된 정의들의 집합을 이용해 데이터베이스 스키마를 구체화한다. 데이터베이스에 저장된 데이터는 해당 데이터베이스가 요구하는 일관성 제약 조건을 만족해야 한다.(ex, 통장 잔고가 음수가 되지 않는 조건) 이런 제약 조건은 DDL을 활용해서 기술한다. 데이터베이스 시스템은 데이터베이스가 갱신될 때마다 이러한 제약 조건을 검토한다.

제약 조건은 데이터베이스와 관련된 임의의 술어(predicate, 데이터베이스 레코드에 대한 부가적인 설명)라 할 수 있다. 하지만 이런 술어를 검증하는 데에는 처리 비용이 많이 든다. 따라서 데이터베이스 시스템은 최소한의 비용으로 검증될 수 있는 무결성 제약 조건을 이행한다.

• 도메인 제약 조건(Domain Constraints). - 모든 속성은 가능한 값의 도메인(정수형, 문자형, 날짜/시간형)이 지정되어 있어야 한다. 속성을 선언하는 데 각각의 도메인은 값에 대한 제약 조건으로 작용한다.
• 참조 무결성(Referential Integrity). - 어떤 속성들의 집합에 대해 릴레이션의 한 값이 다른 릴레이션의 해당 속성 집합의 값으로 반드시 나타나야 하는 경우가 있다(참조 무결성). 예를 들어 각 수업에 열거된 학과가 실제로 존재해야 하는 상황이다. 좀 더 정확하게, course 레코드의 dept_name 값은 department 릴레이션의 일부 레코드의 dept_name 속성에 나타나야만 한다. 데이터베이스의 수정이 참조 무결성을 위반할 경우, 기본적인 절차는 위반을 유발한 동작을 거부하는 것이다.
• 권한(Authorization). - 데이터베이스의 다양한 데이터에 대해서 사용자마다 접근을 다르게 하고 싶을 때 이러한 차별을 일반적으로 권한(authorization)이라 표현한다.

DDL은 다른 프로그래밍 언어와 마찬가지로 명령문(statements)을 입력으로 받아 결과를 생성한다. DDL의 결과는 메타데이터(metadata)-데이터데 대한 데이터-를 수록하는 데이터 사전(data dictionary)에 저장된다. 데이터 사전은 특별한 형태의 테이블로서 일반 사용자들은 접근할 수 없고 오직 데이터베이스 시스템에 의해서만 접근되고 갱신될 수 있다.

1.4.2 SQL 데이터 정의 언어

SQL은 데이터 타입과 무결성 제약 조건을 갖는 테이블을 정의할 수 있도록 풍부한 DDL을 제공한다.

1.4.3 데이터 조작 언어(DML)

데이터 조작 언어(DML)는 사용자가 적절한 데이터 모델로 구성된 데이터에 접근하거나 이것을 조작할 수 있도록 하는 언어다. 접근 형태는 아래와 같다.

• 데이터베이스 내에 저장된 정보를 검색
• 데이터베이스에 새로운 정보를 삽입
• 데이터베이스로부터 정보를 삭제
• 데이터베이스 내에 저장된 데이터를 수정

기본적으로 두 가지 형태의 DML이 존재한다.

• 절차적 DML(procedural DML)은 어떤 데이터가 필요하며 그 데이터를 어떻게 구할지 지정할 것을 요구한다.
• 선언적 DML(declarative DML)은 필요한 데이터를 어떻게 구할지 명시할 필요 없이, 어떠한 데이터가 필요한지 지정할 것만 사용자에게 요구한다.

일반적으로 선언적 DML은 어떻게 필요한 데이터를 구할지 방법을 명시하지 않기 때문에 절자적 DML보다 배우기 쉽다. 하지만 이 때문에 데이터베이스 시스템 스스로 데이터에 효율적으로 접근하는 방법을 찾아야 한다.

질의(query)는 정보 검색을 요청하는 구문이다. 데이터 조작 언어에서 정보 검색을 담당하는 부분을 질의어(query language)라고 한다. 기술적으로 타당하지는 않지만, 질의어와 데이터 조작 언어를 같은 의미로 사용하는 것이 보통이다. 여러 질의어 중에서 현재 가장 널리 쓰이고 있는 질의어는 SQL이다.

1.4.4 SQL 데이터 조작 언어

SQL 질의어는 선언적 언어다.

1.4.5 응용 프로그램에서 데이터베이스 접근

SQL 같은 선언적 질의어는 일반 컴퓨터 언어만큼 강력하지 않다. 즉 SQL로는 불가능 하지만, 일반적인 목적의 프로그래밍 언어를 사용하면 가능한 다수의 계산이 존재한다.

1.5 데이터베이스 설계

데이터베이스 설계는 데이터베이스 스키마 설계와 주로 관련된다. 상위 데이터 모델은 데이터베이스 설계자에게 데이터베이스 사용자의 데이터 요구 조건을 기술하기 위한 개념적인 골격과 데이터베이스가 이러한 요구 조건을 만족하기 위해 어떻게 구성될 것인가에 대한 것을 제공한다. 다음으로 설계자는 데이터 모델을 선택하고, 선택한 데이터 모델의 개념을 적용함으로써 사용자 요구를 데이터베이스의 개념적인 스키마로 바꾼다.

관계형 모델에서 개념적 설계 단계는 데이터베이스에서 우리가 포착하길 원하는 어떤 속성과, 다양한 테이블을 구성하는 이러한 속성을 어떻게 그룹화 할 것인가에 대한 결정과 관련된다.

1.6 데이터베이스 엔진

데이터베이스 시스템은 여러 모듈로 구성되며, 각 모듈은 데이터베이스의 여러 책무를 나누어 맡는다. 데이터베이스 시스템은 기능적인 관점에서 봤을 때 크게 두 부분으로 나뉘는데 저장 장치 관리자(storage manager)와 질의 처리기(query processor)다.

기업입장에서 저장되는 정보의 크기는 매우 크기 때문에 이렇게 큰 용량의 정보는 디스크에 저장된다. 그리고 데이터는 필요할 때마다 디스크 저장 장치에서 메인 메모리로 이동한다. 디스크로부터 데이터를 가져오거나 디스크로 정보를 보내는 작업은 중앙 처리 장치의 속도에 비해 상대적으로 매우 늦기 때문에, 데이터베이스 시스템은 디스크와 메인 메모리 사이의 데이터 이동이 최소화되도록 데이터를 구조화 한다.

질의 처리기는 데이터베이스가 데이터에 접근하는 과정을 단순화하고 효율적으로 만드는 역할을 하기 때문에 중요하다. 질의 처리기는 데이터베이스 사용자가 뷰 단계에서 작업을 하는 동안 시스템의 물리적 단계의 자세한 구현 사항을 이해하지 않아도 되며 좋은 성능을 얻을 수 있도록 해준다. 논리적 단계에서 비절차적 언어로 작성된 갱신 요구와 질의를 물리적 단계의 효율적인 일련의 연산으로 변환하는 것은 데이터베이스의 책임이다.

트랜잭션 관리자(transaction manager)는 응용 개발자로 하여금 일련의 데이터베이스 접근을 (완전하게 수행하거나 혹은 전혀 실행되지 않은 것 처럼) 하나의 단위로 처리할 수 있도록 만들어 주기 때문에 중요하다. 이것은 응용 개발자로 하여금 데이터에 대한 동시 접근의 효과나 시스템 고장에 대한 세부적인 사항을 신경 쓰지 않고 높은 수준의 추상화 단계에서 응용을 생각할 수 있게 만들어 준다.

1.6.1 저장 장치 관리자

저장 장치 관리자(storage manager)는 데이터베이스 하부에 저장된 데이터와 응용 프로그램 및 질의 사이의 인터페이스를 제공하는 데이터베이스 시스템 요소다. 이 저장 장치 관리자는 파일 관리자(file manager)와 상호작용하는 책무가 있다. 원시 데이터는 운영체제상의 파일 시스템을 사용해 디스크에 저장한다. 저장장치 관리자는 다양한 DML 구문을 하위 단계의 파일 시스템 명령으로 변환한다. 그러므로 저장 장치 관리자는 데이터베이스 내의 데이터를 저장하고 검색하며, 갱신하는 책임이 있다.

1.6.2 질의 처리기

질의 처리기는 다음과 같은 구성요소를 가진다

• DDL 인터프리터 - DDL문을 해독하여 데이터 사전 내에 기록한다.
• DML 컴파일러 - 질의어 내의 DML 문을 질의 평가 엔진이 이해할 수 있는 하위 단계 명령어로 구성된 질의 평가 계획으로 바꾼다. 질의는 보통 동일한 결과를 반환한느 여러 가지 질의 평가 계획으로 변환될 수 있다. 여러 질의 평가 계획 중 가장 낮은 비용의 계획을 선택하는 것을 질의 최적화(query optimization)라고 하는데, DML 컴파일러의 책무 중 하나다.
• 질의 평가 엔진 - DML 컴파일러가 생성한 하위 단계 명령을 실행한다.

1.6.3 트랜잭션 관리

보통 데이터베이스에 대한 몇 개의 연산이 하나의 논리적 작업 단위를 이룬다. 예를들어 A가 B에게 이체를 할 때 A는 송금을 완료했지만, B는 입금받은 기록이 없다면 큰 문제가 생길 것이다. 따라서 입금과 출금이 모두 일어나든지, 아니면 모두 일어나지 않든지 하는 것이 필수적이다. 이러한 all or none 요구 조건을 원자성(atomicity)이라고 한다. 또한 예금 이체의 실행은 데이터베이스의 일관성을 보존해야 한다. 즉 A의 잔고와 B의 잔고를 합한 값이 보존되어야 한다. 이러한 정확성에 관한 요구 조건을 일관성(consistency)이라고 한다. 시스템 고장의 가능성에도 불구하고 마침내 예금 이체가 성공적으로 끝난 뒤 A의 잔고와 B의 잔고의 새로운 값이 유지되어야 하는데, 이러한 영속성의 요구 조건을 지속성(durability)이라고 한다.

트랜잭션(transaction)은 데이터베이스 응용 프로그램에서 하나의 논리적 기능을 수행하는 연산의 모임이다. 각 트랜잭션은 원자성과 일관성을 모두 지닌 단위로 수행되어야 한다. 그러므로 트랜잭션은 어던 데이터베이스 일관성 제약 조건도 위반해서는 안 된다. 즉, 트랜잭션이 시작될 때 데이터베이스가 일관성 있는 상태였다면, 트랜잭션이 성공적으로 종료되었을 때도 일관성 있는 상태여야 한다. 하지만 위의 예시에서 A의 계좌와 B의 계좌는 엄밀히 동시에 처리될 수 없고, 한 개씩 처리되며 트랜잭션이 실행되는 동안 일시적으로 불일치-비일관성이 나타난다. 그리고 이럴 때 데이터베이스 시스템에서 고장이 발생하면 치명적인 문제로 발생한다.

각각의 트랜잭션이 데이터베이스의 일관성을 유지하도록 여러 트랜잭션을 적절하게 정의하는 것은 프로그래머의 책임이다. 원자성과 지속성을 보장하는 것은 데이터베이스 시스템 특히 복구 관리자(recovery manager)의 책임이다. 만일 고장이 없는 이상적인 상황이라면 모든 트랜잭션이 성공적으로 잘 수행되고, 원자성도 쉽게 얻을 수 있다. 그러나 현실세계에서는 너무나 많은 고장의 원인이 존재하기에 트랜잭션을 항상 성공적으로 완료할 수는 없다. 원자성의 특성을 보장하기 위해서는 실패한 트랜잭션은 데이터베이스의 상태에 아무런 영향을 미쳐서는 안된다. 따라서 데이터베이스는 트랜잭션이 일어나기 전의 상태로 재저장되어야 한다. 즉 데이터베이스는 고장 복구(failure recovery)를 수행해야만 한다. 즉, 시스템의 고장을 탐지하고 고장 발생 이전 상태로 데이터베이스를 재저장하는 것은 데이터베이스 시스템의 책임이다.

마지막으로, 여러 트랜잭션이 데이터베이스를 동시에 변경하면, 개별 트랜잭션이 정확하고 오류가 없더라도 데이터의 일관성이 유지되지 않을수도 있다. 데이터베이스의 일관성을 보장하기 위해 동시에 실행되는 트랜잭션들 간의 상호작용을 제어하는 것은 동시성 제어 관리자(concurrency-control manager)의 책임이다. 트랜잭션 관리자(transaction manager)는 동시성 제어 관리자와 복구 관리자로 구성된다.